Creating Fields​

We're adding three role custom fields for devices with the Windows Laptop role:

The Script​

loading...

The Results​

You can set this up to run on a schedule - we run this script immediately on machine onboarding and then every 7 days on a Tuesday. This doesn't always have anything to do as our Windows Update run usually handles these updates, but it's a good way to ensure that we're always up to date with the latest drivers from Microsoft Update.

You will find more excellent uses for NinjaOne custom fields on the Dojo, on Stephen Murphy's blog and on Luke Whitelock's blog.

Custom fields are a great way to store arbitrary data from your devices in NinjaOne. In this post I will explore a few examples, some using code from CyberDrain, which store data in NinjaOne custom fields.

This post was updated on 2022/12/22 to add a new script to run a speedtest on a device and store the results in NinjaOne.

loading...

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
Import-Module NJCliPSh
Ninja-Property-Options domainJoinStatus

### Inline Comments

'<MARKED STRINGS>'

loading...

loading...

loading...

loading...

loading...

loading...

loading...

Background information​

Ninja doesn't currently support native AV monitoring via Windows Security Center, integrated AV packages are monitored but what if you need more?

Creating Fields​

We're going to create one role custom field for devices with the Windows Desktop or Windows Laptop role:

The Script​

loading...

Monitoring​

The script includes support for two monitors.

AV Not Enabled​

Setup a script result condition monitor that runs this script with a check for an exit code of 1.

AV Not Up-To-Date​

Setup a second script result condition monitor that runs this script with a check for an exit code of 2.

Background information​

In my quest to stop having to use Windows Sandbox or VMs to access Exchange Online via PowerShell (we have WinRM basic auth disabled) I've been looking at solutions using the Exchange Online REST API to run commands against our customer tenants. The result of my efforts is a pretty complex script that introduces a method to run any PowerShell script in the context of a set of customer tenants.

The script​

loading...

Building Parameters​

Personally I find passing parameters as a HashTable (splatting) easier to read and cleaner see what's happening so that's what I'm doing to explain the parameters for the script:

$EORESTParameters = @{
  PartnerTenantId = (Get-AzKeyVaultSecret -VaultName 'Homotechsual' -Name 'EORESTTenantId' -AsPlainText) # Your partner tenant id.
  ApplicationId = (Get-AzKeyVaultSecret -VaultName 'Homotechsual' -Name 'EORESTClientId' -AsPlainText) # Your SAM application / client id.
  ApplicationSecret = (Get-AzKeyVaultSecret -VaultName 'Homotechsual' -Name 'EORESTClientSecret' -AsPlainText) # Your SAM application / client secret.
  GraphRefreshToken = (Get-AzKeyVaultSecret -VaultName 'Homotechsual' -Name 'EORESTRefreshToken' -AsPlainText) # The Graph refresh t oken provided by the SAM app creation script.
  ExchangeRefreshToken = (Get-AzKeyVaultSecret -VaultName 'Homotechsual' -Name 'EORESTExchangeRefreshToken' -AsPlainText) # The Exchange refresh token provided by the SAM app creation script.
  UPN = '[email protected]' # The UPN of the user used to authorise your SAM tokens.
  IncludeTenants = @('test1.onmicrosoft.com') # Run only on the tenants listed - using the tenant's `DefaultDomainName`. This input is NOT validated.
  ExcludeTenants = @('test1.onmicrosoft.com') # Run on the all tenant except those listed - using the tenant's `DefaultDomainName`.
}

ScriptBlock​

The -ScriptBlock parameter passed to the script runs the commands given against each selected tenant's Exchange Online. You should use the Invoke-EORequest cmdlet in the script block to send commands to ExchangeOnline. For example to get mailboxes:

-ScriptBlock { Invoke-EORequest -Commandlet 'Get-Mailbox' }

More examples are given below.

Result structure​

Before returning values we add a property to object containing the customer's tenant id. This property is called EORCustomerId and is the tenant GUID. You can use this to group results by the tenant they relate to.

| Group-Object -Property 'EORCustomerId'

Example uses​

These examples assume use of the parameter splat above

Get Mailbox Plans​

.\Invoke-EORESTDelegated.ps1 @EORESTParameters -ScriptBlock { Invoke-EORequest -Commandlet 'Get-MailboxPlan' }

Get Shared, Room, Equipment, Group and Team mailboxes​

.\Invoke-EORESTDelegated.ps1 @EORESTParameters -ScriptBlock { Invoke-EORequest -Commandlet 'Get-Mailbox' -Parameters @{ Filter = "((RecipientTypeDetails -eq 'SharedMailbox') -or (RecipientTypeDetails -eq 'RoomMailbox') -or (RecipientTypeDetails -eq 'EquipmentMailbox') -or (RecipientTypeDetails -eq 'GroupMailbox') -or (RecipientTypeDetails -eq 'TeamMailbox'))" } }

Get last login time.​

.\Invoke-EORESTDelegated.ps1 @EORESTParameters -ScriptBlock {
  $Mailboxes = Invoke-EORequest -Commandlet 'Get-Mailbox' -Parameters @{ ResultSize = 'Unlimited' }
  ForEach ($Mailbox in $Mailboxes) { Invoke-EORequest -Commandlet 'Get-MailboxStatistics' -Parameters @{ Identity = $Mailbox.UserPrincipalName } | Select-Object -Property DisplayName, LastLoggedOnUserAccount, LastLogonTime }
}

Get mailboxes not logged into in the last 90 days.​

.\Invoke-EORESTDelegated.ps1 @EORESTParameters -ScriptBlock {
  $Mailboxes = Invoke-EORequest -Commandlet 'Get-Mailbox' -Parameters @{ ResultSize = 'Unlimited' }
  ForEach ($Mailbox in $Mailboxes) { Invoke-EORequest -Commandlet 'Get-MailboxStatistics' -Parameters @{ Identity = $Mailbox.UserPrincipalName } | Where-Object { $_.LastLogonTime -lt (Get-Date).AddDays(-90) } | Select-Object -Property DisplayName, LastLoggedOnUserAccount, LastLogonTime }
}

Get inactive mailboxes.​

.\Invoke-EORESTDelegated.ps1 @EORESTParameters -ScriptBlock {
  Invoke-EORequest -Commandlet 'Get-Mailbox' -Parameters @{ InactiveMailboxOnly = $True }
}

Set hidden from address list for all mailboxes.​

.\Invoke-EORESTDelegated.ps1 @EORESTParameters -ScriptBlock {
  $Mailboxes = Invoke-EORequest -Commandlet 'Get-Mailbox' -Parameters @{ ResultSize = 'Unlimited' }
  ForEach ($Mailbox in $Mailboxes) { Invoke-EORequest -Commandlet 'Set-Mailbox' -Parameters @{ Identity = $Mailbox.UserPrincipalName; HiddenFromAddressListEnabled = $True } }
}

I'm the author of the NinjaOne PowerShell module so when I was looking for a quick way to identify duplicate devices I turned to that module and the NinjaOne API to find a solution.

About this script​

This script is a quick way to identify duplicate devices in your NinjaOne instance. It can return a full listing of all devices grouped by serial number, it can also just return the ID, last contact date and serial number for the device with the oldest last contact date.

The script​

loading...

At this time it's not possible to remove devices via the NinjaOne API so this script will only return the duplicate devices - you'll have to arrange to remove these devices manually.

If you want all devices with duplicates:

Get-NinjaOneDuplicateDevices -All

or just the older duplicated devices:

Get-NinjaOneDuplicateDevices -Duplicates

Did you know, when you have a retention policy configured for OneDrive in Microsoft 365 you lose the ability to recursively delete folders. The OneDrive client often handles this by recursing through the folder tree to remove the online copies but sometimes that doesn't work and in those cases you can end up stuck with a folder tree that you would have to manually recurse to remove the offending folders by first emptying them entirely before OneDrive will let you delete them.

Well that's never going to happen ;-)

Enter PowerShell.

The script​

loading...

Invoking the script​

The script is looking for three parameters, an example invocation to remove a synced "Documents/PowerShell/Modules" folder in Satya Nadella's OneDrive would be:

Remove-OneDriveFolderRecursively -OneDriveHost 'https://microsoft-my.sharepoint.com' -SitePath '/personal/satya_nadella_microsoft_com' -FolderPath '/Documents/Documents/PowerShell/Modules'

Hope this helps!

This post was inspired by a script posted on Microsoft's TechCommunity here...

Background information​

The NinjaOne agent gives you the ability to customise your system tray and add things like about text, email links, a help request form, a URL and other things. Unfortunately HaloPSA doesn't currently support hooking into NinjaOne's help request form (don't worry, we're talking to NinjaOne and Halo Service Solutions about this!) so we're left with a bit of a workaround as a solution.

I've released another PowerShell module; this one is called MSGraphMail and it's a simple PowerShell Graph API email client implementation which was requested by one of our MSP customers to help with transitioning their setup from a legacy SMTP server to Microsoft 365 without redeveloping a very bespoke workflow!

About this script​

HaloPSA is improving at a phenomenal rate - one of the latest enhancements relates to embedding the "customer portal" inside Teams for easier access by customers - this is early days for this enhancement to Halo and at present there isn't really a way to push this tab into customer environments... Until now!

Using the script below you can push any website as a tab to your customers' Teams environments. First a couple of configuration pre-requisites.

1. You'll need to have setup the Secure App Model (Thanks Gav for the superb write-up!)
2. You'll need to know the name of the Team and Channel you want to deploy the tab - currently the script will use the same details for all customers!

The fix​

So here's the script:

loading...

To invoke the script we need to satisfy it's required parameters, an example invocation would look like this:

$NTWTParams = @{
    CustomerExclude = @('example1.onmicrosoft.com', 'example2.onmicrosoft.com')
    TeamName = 'IT Service Desk'
    ChannelName = 'General'
    ClientId = '00000000-0000-0000-0000-000000000000'
    ClientSecret = '00000000-0000-0000-0000-000000000000'
    TenantId = '00000000-0000-0000-0000-000000000000'
    TabName = 'Portal'
    TabURL = 'https://portal.homotechsual.dev'
}
.\New-TeamsWebTab.ps1 @NTWTParams

Breaking down the available parameters:

• -CustomerExclude - An array of customer tenant domains to exclude from the script.
• -CustomerInclude - An array of customer tenant domains to include in the script.
• -TeamName - The name of the Team to add the tab to. Defaults to the default team.
• -ChannelName - The name of the Channel to add the tab to. Defaults to "General".
• -ClientId - The Client ID of your Secure Application Model App.
• -ClientSecret - The Client Secret of your Secure Application Model App.
• -TenantId - The Tenant ID of your partner tenant.
• -TabName - The name of the tab to add.
• -TabURL - The URL of the tab to add.

Once you've filled in the variables - you simply run the script and wait for the tabs to be added!

About this script​

If you're not familiar with the IntuneWin format and what it's used for/when it's used there's some good background reading from Microsoft here: Prepare a Win32 app to be uploaded to Microsoft Intune | Microsoft Docs.

In short, it's a format designed to package Windows application installers for deployment with Intune.

This post contains a script which downloads the latest version of the Adobe Reader DC installer and turns it into an IntuneWin package for Intune deployment.

Kelvin has published a module that automates publishing RMM installers to Intune across all your customer tenants - you can read about it here: Automating with PowerShell: uploading your RMM application to all Intune tenants - CyberDrain.

The fix​

I'm planning a future blog post that integrates these steps into Kelvin's module's workflow providing a single script you can use to get the latest version of Adobe Reader DC and upload it to all your customers' Intune tenants.

loading...

To invoke the script we need to satisfy it's required parameters, an example invocation would look like this:

.\New-AdobeReaderDCInstallPackage.ps1 -Language 'English (UK)' -Architechture 'x64' -InstallerSavePath 'X:\ARDeployment\Src\' -Win32ContentPrepToolPath 'I:\Microsoft\Win32 Content Prep Tool\IntuneWinAppUtil.exe' -PackageOutputPath 'X:\ARDeployment\Output\'

Breaking down the parameters there:

• -Language: Specify the language for the installer. For English (US) use English. A list of valid values can be found at the top of the script.
• -Architechture: The CPU architechture for the installer - valid values are *'x64'* and 'x86'.
• -InstallerSavePath: The folder to save the installer executable into. If it doesn't exist, the script will try to create it.
• -Win32ContentPrepToolPath: The full path to the Microsoft Win32-Content-Prep-Tool executable file.
• -PackageOutputPath: The folder to save the resulting IntuneWin file into. If it doesn't exist, the script will try to create it.