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

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.

O365 Mobile Devices

O365 Mobile Devices

I needed to grab all the mobile devices that had emails attached to them not too long ago. I could have gone through the GUI, and spent a few days trying my best to document everything, or I could use Powershell to pull the O365 Mobile Devices. Can you guess which one I did? Yep, PowerShell is a way of thinking nowadays in the system admin world.

The Script

Connect-ExchangeOnline
$Mailboxes = get-mailbox -all
$Devices = foreach ($Mail in $Mailboxes) {
    $MobileDevices = Get-MobileDevice -Mailbox $mail.userprincipalname
    foreach ($Device in $MobileDevices) {
        $Stats = Get-MobileDeviceStatistics -Identity $Device.Identity
        [pscustomobject]@{
            User = $mail.userprincipalname
            FriendlyName                  = $Device.FriendlyName
            name                          = $Device.name
            Identity                      = $Device.Identity
            DeviceID                      = $Device.DeviceId
            DeviceOS                      = $Device.DeviceOS
            DeviceType                    = $Device.DeviceType
            DeviceModel                   = $Device.DeviceModel 
            ClientType                    = $Stats.ClientType
            FirstSyncTime                 = $Device.FirstSyncTime
            WhenChanged                   = $Device.WhenChanged
            LastPolicyUpdateTime          = $Stats.LastPolicyUpdateTime
            LastSyncAttemptTime           = $Stats.LastSyncAttemptTime
            LastSuccessSync               = $stats.LastSuccessSync
            DeviceAccessState             = $Device.DeviceAccessState
            DeviceAccessStateReason       = $Device.DeviceAccessStateReason
            IsValid                       = $Device.IsValid
            Status                        = $Stats.Status
            DevicePolicyApplied           = $stats.DevicePolicyApplied
            DevicePolicyApplicationStatus = $stats.DevicePolicyApplicationStatus
        }
    }
}
$Devices

The Break Down

This script is pretty straightforward. We first connect to exchange online. Currently, this script is designed to work with MFA. Then we grab all the mailboxes from O365.

Connect-ExchangeOnline
$Mailboxes = get-mailbox -all

Next, we loop through these mailboxes. We drop all the information get gather from this loop into a variable. I called my devices. Once again, nothing great or grand.

$Devices = foreach ($Mail in $Mailboxes) {}

For each mailbox we have, we pull all of the devices from that mailbox. Since a single mailbox can have more than one device, we loop through these devices. For each loop, we want to grab that device’s stats to gain more insights.

$MobileDevices = Get-MobileDevice -Mailbox $mail.userprincipalname
    foreach ($Device in $MobileDevices) {
        $Stats = Get-MobileDeviceStatistics -Identity $Device.Identity

Finally, from there we gather the information into a single object. These commands produce a lot of information. It’s best to parse it down some. That’s what I did with the next part. That’s how I am able to get all the O365 Mobile Devices using PowerShell.

Additional Reading

Set Telemetry with Powershell

Set Telemetry with Powershell

Windows 10 and 11 have a unique feature called telemetry. This feature allows Microsoft to track your device. For security reasons, it’s best to disable this, however, for a home level, this feature is useful. So, let’s Set Telemetry with Powershell.

Registry Keys and Services

There are 4 registry keys that can do this.

  • HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry
  • HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowDeviceNameInTelemetry
  • HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection\AllowTelemetry
  • HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Policies\DataCollection\AllowTelemetry

Along with the registry keys you will need to work with a service called “Diagtrack“. This service while active, can track your computer. To disable telemetry, we must disable diagtrack from the startup and we can do that with Powershell.

Disable Telemetry

Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection" -Name "AllowTelemetry" -Type DWord -Value 0
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection" -Name "AllowDeviceNameInTelemetry" -Type DWord -Value 0
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection" -Name "AllowTelemetry" -Type DWord -Value 0
Set-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Policies\DataCollection" -Name "AllowTelemetry" -Type DWord -Value 0

Get-Service -Name "DiagTrack" | Stop-Service -NoWait -Force
Get-Service -Name "DiagTrack" | set-service -StartupType Disabled

Here we are adding different values. We are setting our 4 registry keys to 0. Then we stop the diagtrack server. Then we set the startup to disabled, This way the service can’t be restarted.

Doing this ensures that the service doesn’t come back to life and if it does, it has no idea what to do.

Enable Telemetry

Remove-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection" -Name "AllowTelemetry"
Remove-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection" -Name "AllowDeviceNameInTelemetry"
Remove-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection" -Name "AllowTelemetry"
Remove-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Policies\DataCollection" -Name "AllowTelemetry"

Get-Service -Name "DiagTrack" | set-service -StartupType Manual
Get-Service -Name "DiagTrack" | start-service

To enable telemetry, we are simply doing the opposite. We remove the registry keys. Then we enable the services. Finally, we start the service.

There you have it, We have Set telemetry with Powershell

Additional Reading

Validate Script Explained

Validate Script Explained

PowerShell is a versatile scripting language that can help automate various tasks for system administrators and developers. One of its key features is the ability to validate script parameters, which can help ensure that the user inputs the correct data. In this blog post, we will explore PowerShell’s Validate Script parameter set and provide examples of how it can be used to test if a webpage is active.

Validate Script is a parameter attribute in PowerShell that allows you to validate the data input by the user before the script executes. This parameter set can be used to define a script block that will be used to test if the input value is valid. The script block should return a boolean value, indicating whether the input is valid or not. If the script block returns false, the user will receive an error message.

To use Validate Script, you need to include it in the parameter block of your PowerShell script. For example:

Param(
    [ValidateScript({Test-Path $_})]
    [string]$Path
)

In this example, the ValidateScript parameter is used to validate the Path parameter. The Test-Path cmdlet is used to test if the input path exists. If the path exists, the script block will return true, and the script will continue executing. Otherwise, the user will receive an error message.

Now, let’s see how ValidateScript can be used to test if a webpage is active. For this, we can use the Test-NetConnection cmdlet to test if the webpage is reachable. Here’s an example:

Param(
    [ValidateScript({Test-NetConnection $_})]
    [string]$Webpage
)

Write-Host "Webpage $Webpage is active."

In this example, the ValidateScript parameter is used to validate the Webpage parameter. The Test-NetConnection cmdlet is used to test if the input webpage is reachable. If the webpage is reachable, the script block will return true, and the Write-Host cmdlet will output a message indicating that the webpage is active.

In conclusion, PowerShell’s ValidateScript parameter set is a powerful feature that can help ensure that the user inputs the correct data. By defining a script block to test the input value, you can ensure that the script will only execute if the input is valid. By using PowerShell cmdlets like Test-Path and Test-NetConnection, you can create custom validation rules to suit your needs. Use this feature wisely and make your scripts more robust and reliable.

Truth

This blog post was created with Chat GPT, what do you think? I don’t like doing 100% auto-generated content like chat gpt. Instead, what I would prefer to do is take the information and work it out. Bring something better and easier to understand. The Chat GPT doesn’t produce SEO good items as well. It produces Passive Voice and requires adjustment. I will not be using Chat GPT to auto-generate blogs like this. If I do need to use the tool, I will always work it and make it much better for you all.