This script-driven health check validates key Intune enrollment indicators and writes the results to NinjaOne custom fields so you can alert on drift quickly.

Creating Fields​

You can run this script without custom fields, but fields are what make it operationally useful in NinjaOne.

The Script​

loading...

What The Script Validates​

The script validates multiple indicators before deciding status:

1. Azure AD join state (AzureADJoined = YES)
2. Microsoft MDM URL presence (MDMUrl)
3. Tenant ID presence
4. Intune MDM device certificate
5. Intune enrollment GUID from EnterpriseMgmt scheduled task path
6. Primary enrollment GUID selection when multiple registrations exist
7. Required MDM enrollment-related registry keys
8. Intune Management Extension service running
9. Last Intune sync event and result status

Script Variables (Ninja Script Variables)​

Expose these as NinjaOne script variables if you want field names to be configurable per environment:

The script now reads Ninja script variables from environment variables with the same names as the parameters.

Example SyncResultLogNames values:

• Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Sync
• Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Sync,Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin

Suggested NinjaOne Monitor Conditions​

A practical first monitor set:

1. intuneEnrollmentStatus != true
2. intuneLastSyncStatus != OK
3. intuneLastSyncAttempt older than your policy threshold (for example, 24 hours)

Use separate alert severities for enrollment failure vs stale sync to avoid noise.

Suggested Severity Tiers​

• Critical: intuneEnrollmentStatus != true
• Warning: intuneEnrollmentStatus = true and intuneLastSyncStatus = Error
• Warning/Info: intuneEnrollmentStatus = true and intuneLastSyncStatus = NoData and intuneLastSyncAttempt is older than threshold

Starter Variable Profile​

If you want a known-good baseline, start with:

• LogTenantId = true
• LogLastSyncAttempt = true
• LogLastSyncStatus = true
• SyncResultLogNames = Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Sync,Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin
• SyncResultEventId = 209

Example Results​

The script reports status cleanly to NinjaOne fields, including enrollment state, tenant ID, sync status, and last sync timestamp.

Deployment Pattern​

A simple rollout approach:

1. Run script daily on all Intune-managed Windows endpoints.
2. Confirm field population on a pilot device group.
3. Enable monitors after two to three successful daily runs.
4. Add dashboards grouped by tenant/site and exception type.

Troubleshooting Notes​

When failures occur, the script output usually points directly to the failing check:

• Device is not Azure AD Joined
• Device does not have a Microsoft MDM URL
• missing enrollment GUID or EnterpriseMgmt task
• missing enrollment registry branch for detected GUID
• IntuneManagementExtension service missing/stopped

NoData can be normal initially on newly enrolled devices until a matching sync result event exists in the selected channel.

intuneLastSyncAttempt is written as an unsigned Unix timestamp (seconds since epoch), which matches NinjaOne Date/Time field validation.

Symptom Quick Map​

This script gives you a practical middle ground:

• Detect when uptime exceeds a threshold
• Notify the logged-in user with a Windows toast
• Optionally let the user schedule an earlier reboot
• Enforce a reboot deadline with a Scheduled Task
• Write policy state and user action back to NinjaOne custom fields

Creating Fields​

This script can run without custom fields, but adding them gives you much better visibility for reporting and follow-up.

The Script​

loading...

Script Variables​

The script has sensible defaults, but these are the key variables to expose in NinjaOne for full control.

How It Works​

1. Reads last boot time from Win32_OperatingSystem and calculates uptime.
2. If uptime is below threshold, it writes Below Threshold and optionally removes any existing reboot task.
3. If uptime is above threshold, it writes Threshold Exceeded, schedules an enforced reboot deadline, and attempts user interaction.
4. If interactive UX is available, the user can:
   • reboot in about 2 minutes
   • schedule an earlier reboot in X hours
   • keep the default deadline
5. Displays a toast showing uptime and reboot deadline details.
6. Writes action/policy fields back to NinjaOne for reporting and monitor logic.

Recommended Deployment Pattern​

A reliable deployment pattern is:

• Schedule this script daily on Windows devices
• Start with the default threshold/deadline (7 days / 24 hours)
• Create a monitor or dashboard using uptimeRebootPolicyState
• Tune threshold by device role (for example, stricter on user endpoints)

For staged rollout, run with dryRun=true first so you can validate logs and field updates without actually creating or removing tasks.

Cleanup Mode​

If you need to roll back or clear existing deadline tasks, set:

• runMode = CleanupOnly

That mode removes the reboot deadline task and exits cleanly.

Notes​

Creating Fields​

We're adding one role custom field for devices with the Windows Desktop or Laptop and/or Windows Server role, note that we've customised slightly the autogenerated machine name here, if you use the default adjust the field name in the script appropriately.

The Script​

loading...

The Results​

We run this script daily and have a corresponding monitor setup to check whether M365 Apps Secure is checked. If it's not, we get an alert and can investigate further. This script has already helped us identify a few devices that were not updating correctly.

In most cases fixing this runs into numerous issues with conflicting versions or files in use. This script is an adaptation of a script by Chris Taylor which takes a different approach to downloading the modules, has a bit more error checking and further installs the new PSResourceGet module which is the replacement for PowerShellGet.

The Script​

loading...

Usage​

.\Initialise-PowerShellGet.ps1

Nice and simple on this one, just run the script and it will do the rest. It does expect a close-to-vanilla install of Windows 10 or 11, so if you've been messing around with the default modules before running this script, it may not work as expected.

The Script​

loading...

:::note Parameters When you run this script you need to pass some parameters. Use -Offline to install using the MSIX file (script will download this if you don't provide it) if you're providing the MSIX provide the path with -MSIXPath. Use -Uninstall to remove the provisioned New Teams package. You can specify your own staging folder with -TeamsFolder. :::

We automate this for the two browsers we support on managed Windows devices (Edge and Firefox) using PowerShell. Here's how we do it.

Edge​

For Edge we're going to be setting the registry key at HKLM:\SOFTWARE\Policies\Microsoft\Edge\PasswordManagerEnabled to 0. This will disable the password manager for all users on the device.

Then we're going to clear out any passwords that may have been saved by deleting the contents of the Login Data file in the user's Edge profile. We'll do this by removing the file entirely.

Now in some cases you only want to do the first part (disabling the password manager) and not the second (clearing out any saved passwords). For that reason the script functionality is controlled with two switch parameters: -DisablePasswordManager and -RemoveExistingPasswords. If you run the script without either of these switches, it will do nothing.

loading...

Firefox​

For Firefox we're going to be setting the registry key at HKLM:\SOFTWARE\Policies\Mozilla\Firefox\PasswordManagerEnabled to 0. This will disable the password manager for all users on the device.

Then we're going to clear out any passwords that may have been saved by deleting the contents of the logins.json file in the user's Firefox profile and any key*.db files. We'll do this by removing the files entirely.

Now in some cases you only want to do the first part (disabling the password manager) and not the second (clearing out any saved passwords). For that reason the script functionality is controlled with two switch parameters: -DisablePasswordManager and -RemoveExistingPasswords. If you run the script without either of these switches, it will do nothing.

loading...

As we don't use Chrome, Opera or Safari, we don't have scripts for those browsers. However for other chromium-based browsers a similar approach to Edge should work. It is possible to do this with Safari on MacOS as well but we haven't yet scripted it.

Wrong! Turns out that it's more than one line!

The Script​

### Inline Comments

'<MARKED STRINGS>'

loading...

Using The Script​

We tested this as a "Script Result Condition" in NinjaOne set to trigger the monitor if a machine's time drifts by more than 10 seconds from uk.pool.ntp.org (the UK's NTP pool) and it worked like a charm. The script is pretty self-explanatory but here's a quick rundown of what it does:

1. It uses a configurable NTP or SNTP server to get the "reference" time. (Parameter -ReferenceServer)
2. It uses the w32tm executable to conduct a number of skew checks against that reference server (Parameter -NumberOfSamples)
3. It averages the samples and compares the result to the threshold (Parameter -AllowedTimeDrift)
4. Optionally you can force a resync if the time drift is greater than the threshold (Parameter -ForceResync)

If the average time drift is greater than the threshold, the script returns a non-zero exit code and the monitor triggers. If the w32tm command errors (non existent server, network down etc) the script returns a non-zero exit code and the monitor triggers.

Credits​

This script borrows ideas and the approach and a little code from the excellent blog of Kevin Holman.

The formidable Chris Taylor helped with a cool suggestion to suppress empty lines in the output and his site is well worth a visit.

The Script​

loading...

:::note Parameters

When you run this script you might want to pass some parameters - here's what they do:

• -Test - This will test the current target version settings and show you the results.
• -Unset - This will remove the target version settings.
• -TargetProductVersion - Specify the target version to aim for, examples would be 21H2 or 22H2.
• -TargetProduct - Specify the target product to aim for, examples would be Windows 10 or Windows 11.

:::

If you're running Windows 10 or 11 you might have come across CVE-2022-41099 which is a vulnerability in the Windows Recovery Environment (WinRE) which could allow a successful attacker to bypass BitLocker if they can boot the device to WinRE. This is a pretty serious vulnerability and Microsoft have released a patch for it. However, the patch is not applied automatically and you need to take action to apply it.

Martin Himken has written a script to patch the WinRE drivers and I've written a script to download and stage the patch and servicing stack update files. The link to Martin's blog is at the top of this post and will be repeated at the end.

This script takes a few parameters to control it's behaviour. Parameter documentation follows:

:::warning -All Using the -All parameter will download a lot of files and take a long time to complete. It is recommended that you only use this parameter if you are patching a large number of devices or want to prepare a cache to serve files from.

Downloading all files consumes roughly 4.9GB of disk space. :::

The Script​

loading...

loading...

Examples​

This example will download the applicable patch and SSU (if applicable) for CVE-2022-41099 to the folder C:\RMM\CVEs\2022-41099.

Get-CVE202241099Patches.ps1 -PatchFolder 'C:\RMM\CVEs\2022-41099\'

This example will download all patches for CVE-2022-41099 to the folder C:\RMM\CVEs\2022-41099. With subfolders for each KB and architecture.

Get-CVE202241099Patches.ps1 -PatchFolder 'C:\RMM\CVEs\2022-41099\' -All

Validating the Fix​

By popular request you can validate the fix using the principles in the script used for CVE detection.

If you're a Windows 10 or 11 user you'll be familiar with the toast notifications that appear in the bottom right of your screen. These are a great way to get a quick message to the user without interrupting what they're doing. In this article we'll look at how to send a toast notification from PowerShell.

We could use the excellent BurntToast PowerShell module to send a toast notification, but in the interests of reducing the number of third-party modules installed on client machines we'll be using the underlying .NET APIs directly as our needs are fairly simple.

Sending toast notifications is fairly simple once you get to grips with the underlying XML schema but we want our Toasts to be next-level so we're going to make them

loading...

# Setup parameter hashtable.
$NotificationAppParams = @{
  IconURI = 'https://homotechsual.dev/img/Icon.png'
  IconFileName = 'homotechsual.png'
  WorkingDirectory = 'C:\RMM\NotificationApp'
  AppId = 'homotechsual.example'
  AppDisplayName = 'Homotechsual Example'
  AppIconBackgroundColor = 0
  ShowInSettings = 1
}
Register-NotificationApp @NotificationAppParams

[CmdletBinding()]
Param(
    # The URI of the app icon to use for the notification app registration.
    [Parameter(Mandatory)]
    [uri]$IconURI,
    # File name to use for the app icon. Optional. If not specified, the file name from the URI will be used.
    [string]$IconFileName,
    # The working directory to use for the app icon. If not specified, 'C:\RMM\NotificationApp\' will be used.
    [System.IO.DirectoryInfo]$WorkingDirectory = 'C:\RMM\NotificationApp\',
    # The app ID to use for the notification app registration. Expected format is something like: 'CompanyName.AppName'.
    [Parameter(Mandatory)]
    [string]$AppId,
    # The app display name to use for the notification app registration.
    [Parameter(Mandatory)]
    [string]$AppDisplayName,
    # The background color to use for the app icon. Optional. If not specified, the background color will be transparent. Expected format is a hex value like 'FF000000' or '0' for transparent.
    [ValidatePattern('^(0)$|^([A-F0-9]{8})$')]
    [string]$AppIconBackgroundColor = 0,
    # Whether or not to show the app in the Windows Settings app. Optional. If not specified, the app will not be shown in the Settings app. Expected values are 0 or 1 (0 = false, 1 = true).
    [int]$ShowInSettings = 0
)

$IconURI = Ninja-Docs-Property-Get "Example Template" "NotificationIconURI"
$IconFileName = 'NotificationIcon.png'
$WorkingDirectory = 'C:\RMM\NotificationApp\'
$AppId = Ninja-Docs-Property-Get "Example Template" "NotificationAppId"
$AppDisplayName = Ninja-Docs-Property-Get "Example Template" "NotificationAppDisplayName"
$AppIconBackgroundColor = Ninja-Docs-Property-Get "Example Template" "NotificationAppBackgroundColor"
$ShowInSettings = 1

if (($null -eq $IconURI) -or ($null -eq $AppId) -or ($null -eq $AppDisplayName)) {
    Write-Error "Required fields are not populated in the Documentation tab."
    exit
}

Well that's setting up the notification app registration. Now we need to actually send a notification using the app.

loading...

# Setup parameter hashtable.
$NotificationParams = @{
  AppId = 'homotechsual.example'
  NotificationImage = 'C:\RMM\NotificationApp\NotificationIcon.png'
  NotificationTitle = 'Example Notification'
  NotificationMessage = 'This is an example notification.'
  NotificationType = 'reminder'
}
Send-Notification @NotificationParams

loading...

There are many other ways you could use notifications and you can add (and handle) actions within notifications but I'm spoiling some killer upcoming blog posts.

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

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​

:::caution Windows Server This script won't work on Windows Server operating systems as they lack a CIM or WMI interface to the Windows Security Center which allows us to easily programmatically query the AV status. :::

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 = 'mikey@homotechsual.dev' # 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 } }
}

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

Well that's never going to happen ;-)

Enter PowerShell.

:::info Required Modules You'll need the PnP.PowerShell module for this script. Install with Install-Module 'PnP.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:

:::tip Double the Documents You'll notice below that the /Documents folder in the path is doubled. This is because the first folder in the OneDrive path is always /Documents then your path starts. In this example we're removing the /Documents/PowerShell/Modules folder. :::

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

title: Getting computer information from your NinjaOne agent into your HaloPSA self service portal authors: mikey tags: [ HaloPSA, NinjaOne, PowerShell ]​

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.

Getting HaloPSA ready​

For this to work we're relying on a feature which Halo released in version 2.73, now this might not be available to you considering 2.72 is the current stable. Still - let's see how we do this and then when you have 2.73 or greater you can configure this yourself.

:::note Halo release notes for this feature...

You can use URI parameters in the self-service portal to set the default value of text custom fields on the new ticket screen Add &customfield_{id} to the URL with {id} replaced with the id of the custom field.

https://myhalourl/portal/newticket?tickettype_id=1&customfield_174=text%20test would set custom field with ID 174 to "text test" by default.

:::

Now that we know how it works - we'll need to add some custom fields to a ticket form in order to get this to work. First though, let's step back a second and check what information we can send from Ninja's agent...

What can NinjaOne provide to Halo?​

We can find the information on what variables NinjaOne provides for use in the various system tray items in this NinjaDojo article. The available variables differ depending on what you're adding to the tray icon, we're interested in Placeholders for Menu Items. These are:

• ${IP_ADDR} - IP Address
• ${USERNAME} - Username of current user
• ${HOSTNAME} - Machine hostname
• ${DOMAIN} - Domain that the machine has joined
• ${TIMESTAMP} - Current timestamp in ISO format (UTC)
• Any other environment variable - for example ${PROCESSOR_ARCHITECTURE}

That last one is pretty important, any environment variable - so what information might that include? Run Get-ChildItem ENV: in a PowerShell session to get a list of currently available environment variables. Useful environment variables include ${COMPUTERNAME} but it's also worth noting that you can set environment variables from your NinjaOne scripts - we often set environment variables that indicate the state of key components - e.g. OneDrive status.

Back to setting up HaloPSA​

So back to HaloPSA, we're heading to Configuration -> Tickets -> Ticket Types selecting the ticket type we want our users to create from the NinjaOne tray, in our example we're going to use Incident - make sure you check the URL for the tickettypeid which for ours, in our example, is 1.

Click on Field List then click on Edit and finally Add, you'll be presented with a popup that lets you select existing Field Groups or add new ones using the Add button.

We're going to create a Field Group to hold our fields which will be coming from NinjaOne. So we're going to click on New on the Field Groups page, we're going to enter a name, in our case we're calling this NinjaOne and we're inputting a Group Header to mark these fields on the form as Device Information.

Save your field group then click on Field List and click Edit. We're going to add some fields using Add.

You'll see all custom fields available to you here to add to your group, many of the ones you want are probably already there, if not - go to Configuration -> Custom Objects -> Custom Fields and add new fields to the Ticket entity.

In our example we're adding a custom field called Computer Name

Make sure when you add a field that you grab the field id from the URL, in our case this was 170. Once we've added the field(s) it should look like this:

Let's pop onto the portal and check whether the field shows up, it does! Great! Now if we didn't get the ID previously we can right click the field, hit Inspect Element and grab the number from the end of the id attribute.

So, we know we want a link to create a ticket (of type id 1) which fills in custom field (with id 170) with the value of ${COMPUTERNAME} from NinjaOne. So let's string that together ready for NinjaOne...

https://yourhalo.portal.example/newticket?tickettype_id=1&customfield_170=${COMPUTERNAME}

That's it - that's our link, if we wanted to add more custom fields we just append them to the end &customfield_nnn=${variable}.

Adding the link to the SysTray icon​

So we're going to head to Configuration -> Branding -> Systray Icon in NinjaOne and Add Menu Item, we want type URL, we're going to give it the label Open a Service Desk ticket..., we're going to pop our URL from earlier in and then hit Save.

That's it!

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!