Read Radius Logs With PowerShell

Read Radius Logs With PowerShell

Recently, I have been troubleshooting radius. Radius hasn’t changed in decades. I say this lightingly too. The network policy server is a feature that helps with connecting things like unifi wifi and more. Each radius connection produces a reason code. Today we want to look through the radius logs and get as much useful information without screaming at the screen. Radius logs are a little daunting. This is why many people use an SQL server for the radius logs. However, if you are not one of those people who can do this, the traditional radius logging works wonders. So, we will read radius logs with PowerShell.

Radius Logging

Before we start, we need to know what we are dealing with. The standard location for readius logs is: C:\Windows\System32\LogFiles. You can change this location as you see fit. I personally changed my locations to a c:\logs\radius location. This helps me find it quicker and generally, I don’t have trouble guessing what is what. You can set the radius log location by doing the following:

  • Start Network Policy Server
  • Click account
  • Under Log File Properties click Change Log File Properties
  • A box will pop up called “Log File Properties” Click on the “Log File” tab.
  • This is where you can change your directory.
  • Change your Format to DTS Compliant. As this script works best with it.
  • I personally like smaller files when I am working with log searches. So I select the “When log file reaches this size:” I select 1 – 5 MB.
  • Click ok

Now your log files will live wherever you told them. You will need to change the script around a little if you are using a different location than me.

The Script and Breakdown

$NPSLogs = Get-content -Path "C:\Logs\Radius\IN2308.log" | Select-Object -Last 6
foreach ($NPSLog in $NPSLogs) {
    [pscustomobject][ordered]@{
        TimeStamp = ([xml]$NPSLog).event.Timestamp.'#text'
        ComputerName = ([xml]$NPSLog).event.'Computer-Name'.'#text'
        Sources = ([xml]$NPSLog).event.'Event-Source'.'#text'
        Username = ([xml]$NPSLog).event.'User-Name'.'#text'
        CalledStationId = ([xml]$NPSLog).event.'Called-Station-Id'.'#text'
        CallingStationId = ([xml]$NPSLog).event.'Calling-Station-Id'.'#text'
        NasPortType = ([xml]$NPSLog).event.'NAS-Port-Type'.'#text'
        NasIdentifier = ([xml]$NPSLog).event.'NAS-Identifier'.'#text'
        NasPort = ([xml]$NPSLog).event.'NAS-Port'.'#text'
        ClientIPAddress = ([xml]$NPSLog).event.'Client-IP-Address'.'#text'
        ClientVendor = ([xml]$NPSLog).event.'Client-Vendor'.'#text'
        ClientFriendlyName = ([xml]$NPSLog).event.'Client-Friendly-Name'.'#text'
        ProxyPolicyName = ([xml]$NPSLog).event.'Proxy-Policy-Name'.'#text'
        ProviderType = ([xml]$NPSLog).event.'Provider-Type'.'#text'
        SamAccountName = ([xml]$NPSLog).event.'SAM-Account-Name'.'#text'
        FQUsername = ([xml]$NPSLog).event.'Fully-Qualifed-User-Name'.'#text'
        AuthType = ([xml]$NPSLog).event.'Authentication-Type'.'#text'
        Class = ([xml]$NPSLog).event.Class.'#text'
        PacketType = ([xml]$NPSLog).event.'Packet-Type'.'#text'
        ReasonCode = ([xml]$NPSLog).event.'Reason-Code'.'#text'
        TunnelClientEndpt = ([xml]$NPSLog).event.'Tunnel-Client-Endpt'.'#text'
    }
}

As you can tell, this script needs to be used on the server in question. However, You could wrap this script into a nice wrapper. That would allow you to execute on remote machines. The breakdown is very simple on this one as well. DTS is an XML format. Thus, you just need to use the [XML] before any of the lines. The XML is formatted with the event, it’s name, and the text. It’s a very simple setup. From there I select what I want and give it in a pscustom object. That’s it. Its a very simple setup. That’s why we should always read radius logs with Powershell.

Speedtest To Ninja

Speedtest To Ninja

In a previous blog, we discussed doing a speed test on a computer using PowerShell. Let’s take that script and expand on it with three lines of code and some prep time. This will allow us to update items inside our Ninja One RMM tool. So we can push a Speedtest To Ninja One.

What’s Ninja One?

Ninja One is an amazing RMM tool. I have used many different ones over the years and Ninja one blows my mind. it has a strong community behind it and it keeps growing. It’s the only rmm tool that isn’t afraid to make mistakes and grow. When in used continuum, I saw many times, largely requested items went to the void. While in ninja, It never goes to the void. So, if you are looking for a Good RMM, Ninja One is amazing. With that said, let’s go deep into custom fields and how to set them up for script inputs.

Ninja One Custom Fields

There are currently two ways to make a custom field for a computer. The first is global. This means all companies, roles, and devices will have them. The other way is through the roles. Both options live under the Administration > Devices. Today we are going to setup a Role Custom Field. We are going this route because we don’t want the isp speed check information for internal servers and such.

  1. Click Administration
  2. Click Devices
  3. Click Role Custom Fields
  4. Click The Add Button
  5. Click Fields

This next part is important. The label is the text that you will read. The Name is what will be used to call the field later. The field type is what you will make it. For example, multi text, text, date, etc… The first custom field will be the following:

  1. Label: ISP
  2. Name: isp
  3. Type: text

When you click create, the next window will appear. This window is more important. This is where you can choose to allow scripts, APIs and more. If you are planning to allow your technicians to edit this field, then set the technician to editable. The next is script. This is where the script comes into play. This allows the Ninja command line interface to push the Speedtest to Ninja. It has to be at least write for it to work. Next, is the API option. If you are planning to do some special API stuff, this is where you give your field permissions for the APIs. The label is just a label, the description is just a description, the tooltip allows you to give context, the footer text is just that, footer text and finally, you can make it required.

Speedtest to Ninja One

Follow the same steps to create the DownloadSpeed, and UploadSpeed fields. You want them both to be text and you want the script to be at least write. Now, if you have done all that, you are ready to add the ninja command line to the speed test script. This is going to be shockingly easy. The first step is to put your return into a return variable.

$returnInfo = [PSCustomObject]@{
    Server     = $server
    ISP        = $ISP
    Download   = $DownloadSpeed
    Upload     = $uploadSpeed
    ResultsURL = $SpeedTestURL
}

Once you have a returnable variable, let’s pass them into the Ninja One command line interface. First notice the PowerShell module name is NJCLiPSh. The commands all start with Ninja. If you want to dig deeper, you can read up on the Ninja One documentation. I will place additional resources at the end.

The command we are going to be using to update our custom fields is “Ninja-Property-Set”. This command will allow us to set any “script” enabled property. It’s as simple as stating the name and value. The auth from the computer will confirm everything is right and update only that device’s property. It’s amazingly simple.

Ninja-Property-Set isp $returnInfo.ISP
Ninja-Property-Set DownloadSpeed $returnInfo.Download
Ninja-Property-Set uploadspeed $returnInfo.Upload

There are many more things you can do with this script. After building out the Speedtest script, I found out someone else did it better. Which is normal and ok. Check out Mikey O’Toole’s exploring into custom fields, here. He goes through different ways to address the custom fields.

Speed test with PowerShell

Speed test with PowerShell

Often times I need to run a speed test on a remote machine. Doing a speed test tends to help you understand what’s going on with the end user’s computer. For example, currently, my ISP is having issues. I am getting around 6mbps down and 75 Mbps up. If I called in and said I couldn’t watch training videos… that’s why. so it’s essential to know the speeds. That’s why we want to do a speed test with Powershell.

The Script

#Tests if C:Temp Exists, If it doesn't, makes it. 
$CTemp = "c:\Temp"
if (!(Test-Path $CTemp)) { New-Item -Path "c:\" -Name Temp -ItemType Directory }
if (!(Test-Path "$CTemp\SpeedTest")) { New-Item -Path "c:\" -Name Temp -ItemType Directory }

#Download the Speed Test Tool. 
$URL = "https://install.speedtest.net/app/cli/ookla-speedtest-1.0.0-win64.zip"
$DownloadPath = "$CTemp\SpeedTest.Zip"
if (!(Test-Path $DownloadPath)) { Invoke-WebRequest -Uri $URL -OutFile $DownloadPath }

#Expand the Zip File
Expand-Archive $DownloadPath -DestinationPath "$CTemp\Speedtest" -Force

$test = & "C:\temp\Speedtest\speedtest.exe" --accept-license

$DownloadSpeed = [regex]::match(($test | where-object { $_ -like "*Download:*" }).trim(), '[0-9]+\.?[0-9]*').value
$uploadSpeed = [regex]::match(($test | where-object { $_ -like "*Upload:*" }).trim(), '[0-9]+\.?[0-9]*').value
$ISP = ($test | where-object { $_ -like "*ISP:*" }).trim().split(":")[1].trim()
$server = ($test | where-object { $_ -like "*Server:*" }).trim().split(":")[1].trim()
$SpeedTestURL = ($test | where-object { $_ -like "*Result URL:*" }).trim().split(" ")[2].trim()

[PSCustomObject]@{
    Server     = $server
    ISP        = $ISP
    Download   = $DownloadSpeed
    Upload     = $uploadSpeed
    ResultsURL = $SpeedTestURL
}

The Breakdown of the Speed test with PowerShell

As we enter this script, you can see my laziness already. The first thing I do is make a string called ctemp for the “c:\temp”. This way I don’t have to type “c:\temp” repeatedly. Next, we test the path to see if c:\temp exists. If it doesn’t, we make it. We do this with the new-item command with the name as temp and the item type as a directory. We do the same thing with c:\temp\speedtest for later. If you really want to get fancy, you can replace the C: with an $env:systemdrive.

Building the folders

$CTemp = "c:\Temp"
if (!(Test-Path $CTemp)) { New-Item -Path "c:\" -Name Temp -ItemType Directory }
if (!(Test-Path "$CTemp\SpeedTest")) { New-Item -Path "c:\" -Name Temp -ItemType Directory }

The next step is to download the speed test application from ookla. We need the URL and where it’s going to be downloaded. That’s why the URL has the URL needed. We want to call the file speedtest.zip. Next, we test to see if we already downloaded it. If we didn’t, we download the file using the invoke web request and the out file tags.

Downloading the app

$URL = "https://install.speedtest.net/app/cli/ookla-speedtest-1.0.0-win64.zip"
$DownloadPath = "$CTemp\SpeedTest.Zip"
if (!(Test-Path $DownloadPath)) { Invoke-WebRequest -Uri $URL -OutFile $DownloadPath }

Once we have the file downloaded, we need to extract the Speed test files. We use the expand archive command to force the download to the c:\temp\speedtest folder that we made at the beginning. I use the force flag here to overwrite anything just in case the file was already there.

Expanding the drive

#Expand the Zip File
Expand-Archive $DownloadPath -DestinationPath "$CTemp\Speedtest" -Force

Next, we run the Speed test with PowerShell. In PowerShell, you can run apps directly inside the shell and input that data directly into the shell by using the & sign. With this software, we need to accept the license if we want to do this script without human interaction. Finally, we want to push its output into a variable. Since it’s a test, let us call it a test.

Running the Speed test with PowerShell

$test = & "$CTemp\Speedtest\speedtest.exe" --accept-license

The variable $test contains a few strings with the information we need. It’s time to work with those strings. The string contains the server, isp, download, upload, and jitter information. Here is an example output of what this little program produces:

Speedtest by Ookla

     Server: Piedmont Redacted
        ISP: Spectrum Business
    Latency:    22.46 ms   (0.12 ms jitter)

   Download:   166.84 Mbps (data used: 217.5 MB)

     Upload:   194.09 Mbps (data used: 224.6 MB)
Packet Loss:     0.0%
 Result URL: redacted

The first item I want to extract is the download. The code is a little complex so lets start from the inside. We start off with our $test variable. We want to find the string line that contains “Download:” and then trim that up.

($test | where-object { $_ -like "*Download:*" }).trim()

Next, we need to wrap this inside a regex match. We are using the .net structure here using the [regex]:match. Don’t use matches, it will give you additional information. The match uses our variable and the regex to match with. The regex is the hardest part. So let’s take it apart.

The Regex

'[0-9]+\.?[0-9]*'

The first part [0-9] is searching for characters 0 – 9. However, it only looks at the first digit. The + looks for the rest until we reach a “.”. The “\” is before the “.” because “.” is a used variable in regex. If we stop here, we only get the first part of the download speed. We don’t get anything past the “.”. So we add the “?”. Once we do this it allows us to continue. At this point, we look for another [0-9]. Once again, it’s just the first character. We want everything past that so we add the “*”. Now we have the first match. This is the download speed. Once we have the regex information we ask for only the value. We do this with the upload speed as well.

$ISP = ($test | where-object { $_ -like "*ISP:*" }).trim().split(":")[1].trim()
$server = ($test | where-object { $_ -like "*Server:*" }).trim().split(":")[1].trim()
$SpeedTestURL = ($test | where-object { $_ -like "*Result URL:*" }).trim().split(" ")[2].trim()

Now, we need to work with The ISP. We search for the “ISP:” inside our test variable. Like before, we trim up the string. This removes the spaces at the start and end. Then we split this string with the “:”. The split is here because it makes sense. We select the second object from that split as it contains the text. The first, which is also 0, doesn’t contain the text. Now we have the string, we once again trim it up. There you go. That’s the ISP. We do the same thing with the server as the ISP. The results URL is a little different. We split the space and then select the third object.

Displaying the information

Finally, we create a PS custom object and place each piece of useful information into it. When you launch the script, this information will return and you can see it inside your rmm feedback. From here, you can add this information to your RMM tool in custom fields if you wish. Since I use Ninja at the moment, I will go over that later.

That’s it, Speed Test with PowerShell is at your fingertips. I hope you enjoy it.

Additional Resources

Automating with Graph API

Automating with Graph API

Last week we discussed sending emails with Graph API. You can read about it here. Today we will be taking that script and making it so it can be automated. On the backend, you will need to create an Azure App. You can read about how to do that here. The following code only works in Powershell 7 and above. Automating with Graph API works best in PowerShell 7. You will need to set up your App with Users.Read.All and Mail.Send as the minimal. levels.

The Script

import-module Microsoft.Graph.Users
Import-module Microsoft.Graph.Users.Actions  

$EmailToSend = "A Cloud Email @ your domain"
$EmailToReceive = "Any Email"
$AppID = "This is your App ID"
$SecuredPassword = "This is your Password"
$tenantID = "This is your tenant ID"

$SecuredPasswordPassword = ConvertTo-SecureString -String $SecuredPassword -AsPlainText -Force
$ClientSecretCredential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $AppID, $SecuredPasswordPassword

Connect-MgGraph -TenantId $tenantID -ClientSecretCredential $ClientSecretCredential

#Connect-MgGraph -Scopes "User.Read.All, Mail.Send"
$users = Get-MgUser -filter "accountenabled eq false"
$ReturnString = ""
foreach ($user in $users) {
    if ($null -ne (Get-MgUserLicenseDetail -UserId $user.Id)) {
        [pscustomobject][ordered]@{
            UPN      = $user.UserPrincipalName
            Licenses = (Get-MgUserLicenseDetail -UserId $user.id).SkuPartNumber -join ", "
        }
        $ReturnString = $ReturnString + "$($user.UserPrincipalName): $((Get-MgUserLicenseDetail -UserId $user.id).SkuPartNumber -join ", ")`n"
    }
}
 
$body = @"
<html>
<header>Licenses</header>
<body>
<center>
<h1>Disabled Users</h1>
<h2>With Licenses</h2>
</center>
$ReturnString
</body>
</html>
"@
$params = @{
    message = @{
        subject = "Disabled Users with Licenses"
        body = @{
            contentType = "HTML"
            content = $body
        }
        toRecipients = @(
            @{
                emailAddress = @{
                    address = $EmailToReceive 
                }
            }
        )
    }
    saveToSentItems = "false"
}
 
# A UPN can also be used as -UserId.
Send-MgUserMail -UserId $EmailToSend -BodyParameter $params

The Breakdown

This script is the same as last week’s except for how it connects and how you feed the email addresses. We are using the Client Secret Credential flag, which is only available in Powershell 7, to trigger the connect command. You need some basic information first. This information will allow Automating with Graph API to work.

$AppID = "This is your App ID"
$SecuredPassword = "This is your Password"
$tenantID = "This is your tenant ID"

The App is the application ID from the azure app you created. the tenant ID is also the tenant ID of the azure app you created. Remember, I stated to keep the secret key value. This is where you will use it. Place it in the Secure Password area. Next, we need to convert this information into a secure object.

$SecuredPasswordPassword = ConvertTo-SecureString -String $SecuredPassword -AsPlainText -Force
$ClientSecretCredential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $AppID, $SecuredPasswordPassword

Now, we need to convert the plain text to a secure string. We do this with the convertto-securestring command. We enter the string and force it with the force tag. Once we have done that, we want to create a credential object. We use the new-object command to create an automation pscredential object. We feed it the appID and the password we created above. This gives us the ps object that we will use for the next part.

Connect-MgGraph -TenantId $tenantID -ClientSecretCredential $ClientSecretCredential

Using the connect-mggraph command we connect to our tenant and pass the app id and password as a single object. This will connect us directly to Graph API. Later we will run this script through the task scheduler. The remainder of the script will stay the same. Finally, we supply the email addresses. Automating with Graph API couldn’t be easier. So Enjoy!

Additional Links

Emails with Graph API

Emails with Graph API

Last week we spoke about finding disabled users with licensing using PowerShell and graph API. Today, we will be expanding from that blog. We are going to send the results ourselves. Next week, we will create this into an automation using application rights and azure apps. However, today we will send Emails with Graph API and Powershell.

The Script

import-module Microsoft.Graph.Users
Import-module Microsoft.Graph.Users.Actions  

Connect-MgGraph -Scopes "User.Read.All, Mail.Send"
$users = Get-MgUser -filter "accountenabled eq false"
$ReturnString = ""
foreach ($user in $users) {
    if ($null -ne (Get-MgUserLicenseDetail -UserId $user.Id)) {
        [pscustomobject][ordered]@{
            UPN      = $user.UserPrincipalName
            Licenses = (Get-MgUserLicenseDetail -UserId $user.id).SkuPartNumber -join ", "
        }
        $ReturnString = $ReturnString + "$($user.UserPrincipalName): $((Get-MgUserLicenseDetail -UserId $user.id).SkuPartNumber -join ", ")`n"
    }
}

$EmailSend = Read-Host "Email Address to send (Cloud Only)"
$Emailreceive = Read-Host "Email Address to Receive"

$body = @"
<html>
<header>Licenses</header>
<body>
<center>
<h1>Disabled Users</h1>
<h2>With Licenses</h2>
</center>
$ReturnString
</body>
</html>
"@
$params = @{
    message = @{
        subject = "Disabled Users with Licenses"
        body = @{
            contentType = "HTML"
            content = $body
        }
        toRecipients = @(
            @{
                emailAddress = @{
                    address = $Emailreceive
                }
            }
        )
    }
    saveToSentItems = "false"
}

# A UPN can also be used as -UserId.
Send-MgUserMail -UserId $EmailSend -BodyParameter $params

The Breakdown

The same

Like last week, we are using the Microsoft Graph PowerShell module. The first part of this code is the same as last week. So you can take a good read on that one. The only difference is our scope. We are adding mail.send. Mail.Send allows us to send emails from cloud users. It will not work with inactive, soft-deleted, or on-premise-hosted devices. Thus the connect-mggraph will look like the below

Connect-MgGraph -Scopes "User.Read.All, Mail.Send"

The only other thing we have added to the original script is a return string. We initialize the return string with a $returnstring = “” and then we build the string out. Using the same as before, we grab the SKU part number. Finally, we use the join. The difference is we wrap the command in a bubble, $(), for our string. Then we put the sting, the new information, and a line break, `n, into the string.

$ReturnString = $ReturnString + "$($user.UserPrincipalName): $((Get-MgUserLicenseDetail -UserId $user.id).SkuPartNumber -join ", ")`n"

Emails with Graph API

The first thing we want to know is Who we are sending the email to and Who is sending the email. The one sending the email has limitations. First, it can’t be an inactive user. The user can’t be in a soft-deleted state. Finally, it has to be hosted in the cloud. The person we are sending to has to have an email box.

The next part is where we create the email we are going to send. Remember that returnstring we made a few moments ago, it’s time to use that. We are using a here string. Here strings allows large string data like an HTML page, to be placed into a string. Here strings are set apart using the @ symbol. Take a look at the $body below.

$body = @"
<html>
<header>Licenses</header>
<body>
<center>
<h1>Disabled Users</h1>
<h2>With Licenses</h2>
</center>
$ReturnString
</body>
</html>
"@

Params

Please note that some PowerShell ide does not like the tabbing inside a here-string. The next part is the parameters of the email system. We are sending a message. Additional documentation can be found here. We are going to use the following tags, subject, body, to recipient, and save to sent items. All of these items are setup as a Json file as the API uses Json as well.

  • Subject: What is the subject of the email
  • Body: body contains the content type and the content. Here is where we will be using our $body.
  • To Recipients: This is where the email addresses will go. We set up an email address and have it as an array.
  • Save to Sent Items: Finally, we determine if we want this item to stay in our sent items.
$params = @{
    message = @{
        subject = "Disabled Users with Licenses"
        body = @{
            contentType = "HTML"
            content = $body
        }
        toRecipients = @(
            @{
                emailAddress = @{
                    address = $Emailreceive
                }
            }
        )
    }
    saveToSentItems = "false"
}

Finally, we use the send-mgusermail command. This is where we use the send email. It will be the UPN of the target user we want to send email from. The body parameter will be the parameters we just built. Once you do this, you will see the email come in accordingly. That’s how you can send Emails with Graph API.

Find Disabled Users with Graph API and Powershell

Find Disabled Users with Graph API and Powershell

Microsoft licensing can cost a lot of money. It’s not logical to have a disabled account have licenses. Some licenses can cost up to $25 USD a month. So if you have 4 of these disabled accounts with licenses, that could easily be 100 per month. Let us Find Disabled Users with Graph API using PowerShell and find which ones have licenses.

Today’s post will be using the Microsoft.graph.users module. We can connect to graph API via the API, or we can use the Powershell module. In previous posts, I have shown how to connect to the API and pull information. This is still one of the best methods to use as the Graph API module has no way to search for things like shared mailboxes. I will cover that in a later post. So, let’s dive into the graph users module. You can read the documentation here.

The script

import-module Microsoft.Graph.Users
Connect-MgGraph -Scopes "User.Read.All"
$users = Get-MgUser -filter "accountenabled eq false"
foreach ($user in $users) {
    if ($null -ne (Get-MgUserLicenseDetail -UserId $user.Id)) {
        [pscustomobject][ordered]@{
            UPN = $user.UserPrincipalName
            Licenses = (Get-MgUserLicenseDetail -UserId $user.id).SkuPartNumber -join ", "
        }
    }
}
Disconnect-mggraph

The Breakdown

First of all, look at how little code there is compared to the previous post. The Connect-MGGraph removes so much back end work. When you run this command it will prompt you to grant it permissions. Once you disconnect, those permissions disappear. if you have a global admin account, if you don’t put in a scope, you gain access to everything. Which is super nice and scary. I prefer to have scope so I don’t break things.

If you don’t have the “Microsoft.Graph.Users” module, install it. You can install it by using the install-module commandlet.

Connect-MgGraph -Scopes "User.Read.All"

Like I said before, The connect-MGgraph command allows you to do scopes. This is very important. Back in the day we used msol. When we connected we had full control unless we limited our accounts which caused issues. In this case we are creating a temporary azure app. See the previous post about how to make an azure app. You will see how time saver this command can be. That azure app will have the scopes that you give it. If you don’t give it a scope, it has your rights. So, if you are a global admin, you can do damage on accident. It’s nice not to be in the scary ages anymore. So give it scope. In this case we are using User.Read.All as our scope. The User.Read.All permissions will help us Find Disabled Users.

$users = Get-MgUser -filter "accountenabled eq false"

The next part is where we grab all the disabled accounts. Using the Get-MgUser commandlet, we trigger the filter option. We want only accounts that are not enabled. thus the account enabled is equal to false. Very simple idea. If you run users[1] you can see the items you can search with. I do not suggest searching for anything to crazy.

The loop

Now we have all the disabled accounts we want to find the Licensed ones. We need to create a for each loop. Foreach loops are a staple for data controls. Without it… it’s just a pain. As we loop, we want to find the ones with a licenses. We need the user id from the account. So the best thing to do is do an if statement.

foreach ($user in $users) {
    if ($null -ne (Get-MgUserLicenseDetail -UserId $user.Id)) {
       #Do Something
    }
}

In this if statement we pull the licenses using the Get-MgUserLicenseDetail with the users id. If there is nothing that comes from this command it will return a null. So we test null against the command. It’s slightly faster than testing the command against null. Every user inside this if statement that is true will have a licensing. We want to display that information.

[pscustomobject][ordered]@{
        UPN = $user.UserPrincipalName
        Licenses = (Get-MgUserLicenseDetail -UserId $user.id).SkuPartNumber -join ", "
}

Here we create a PowerShell custom object. We want to display the User Principal Name, also known as, the sign name. We do this by using the $user from the foreach loop and just tag the user principal name. Next, we want to display all the licenses. The licenses come as an array. For example, my test account has 3 licenses. I want all that as a string. So, we use the Get-mguserlicensedetail command. We pull out the SKU part number. Then we do some array magic. The -join “, ” converts the array into a string. At the end of each line it adds a “,” and a space. Which makes it easier to read. The cool part about this is if it’s just one license, we it will not add the “, ” to the end. This makes it super readable.

One catch though, thanks to how Microsoft likes to hide things, the SKU is going to be coded. For example, it might say spe_f1. which means it’s an F1 license for Microsoft office. while of1 could mean the same thing but purchased from a different location. I use to try to keep a living list, however, these sku change daily and finding them will be hard. This is where Google is your friend.

Disconnect-MgGraph

Finally, we disconnect from graph API. We don’t want that app to stay there do we? Yeah, we disconnect like good admins we are. Once you are disconnected, you can review all the information this script provided. I am not a big fan of automating the removal of licenses through this method because many times other admins will licenses disabled accounts to keep email alive as a shared mailbox or other oddities. Right now, graph API poweshell module just doesn’t work with shared mailboxes. It is on the workbooks though.

Now go, Find Disabled Users With Graph API and Powershell, and Enjoy your day.