NinjaRMM deployment lacks Location entry parameter, annoying default of "first returned" used instead

Software, Tasks & Script Requests
1

There’s a Location field in NinjaRMM that is pulled in via the API, but the deployment Software task simply grabs the first one returned by the API (alphabetically it looks like) and uses it. This is sometimes OK if unspecified, but would love to either have an argument we can configure to specify the location name to use (very easy based on PowerShell but I can’t edit the global software or tweak the PowerShell directly), or even better would be to enter a set of “preferred” location names and have it use one of them if it exists, or default to the first-available if there’s no match in a customer (or even just use the defined location name only IF there’s more than one location returned by the API, otherwise use the default location provided).

Copying the entire software deployment to be able to add the parameter and do this myself seems like a lot of work just for this change, but I’ve contemplated it…would prefer a global tweak :slight_smile:

2

So is the idea here that you’re going to go from having a single cross tenant deployment to having one deployment per tenant?

3

I’m open to another solution, but I need to have the location in NinjaRMM be the main one for a client and not whichever one the API returns first, at least for 5-10% of our clients (the rest only have one location). Ideally a per-tenant override, but a cloned deployment that wins in those tenants with a location name would suffice (and avoid needing to generate a MSI manually from Immy and use by URL, which works “ok” but if we link directly and don’t self-host the path changes after every agent version upgrade). Would prefer to use the API throughout from Immy and override location as needed.

My suggestion to set a preferred location name or list of names would be to use one deployment but add hints for the multi-location clients without breaking single-location organizations from the same deployment, but it’s not an entirely clean solution either.

4

Out of curiosity, what exactly are you using Ninja locations for? I am a Ninja user and have found no practical use for locations.

5

New Ninja user here; at the moment it’s a logical separation for filtering. Physical offices, Azure Virtual Desktops, etc. Internally also using a New Devices holding location. They sync with Autotask locations. They’re also working to add location-based policies at some point soon, though they don’t exist yet.

6

I started to use locations when we started on Ninja ~2 years ago. I got tired of manually moving devices between locations. We ended up writing a script that runs weekly to change the device name to “AutotaskID-” based on the subnet of the device. Example for a client:

#Set the Graph profile to Beta - Beta provides more functionality
Select-MgProfile -Name beta

# Get Windows Devices by Id
$WindowsDevices = Get-MgDeviceManagementManagedDevice -All -Filter "OperatingSystem eq 'Windows'" -Select Id

# Cycle
foreach ($WindowsDevice in $WindowsDevices) {
    $WindowsDeviceDetails = Get-MgDeviceManagementManagedDevice -ManagedDeviceId $WindowsDevice.Id -Select DeviceName, HardwareInformation
    $DeviceName = $WindowsDeviceDetails.DeviceName
    $SerialNumber = $WindowsDeviceDetails.HardwareInformation.SerialNumber

    switch ($WindowsDeviceDetails.HardwareInformation.SubnetAddress) {
        "10.131.12.0" { 
            $AutotaskId = "188-"
        }
        "10.131.15.0" { 
            $AutotaskId = "189-"
        }
        "10.131.3.0" { 
            $AutotaskId = "191-"
        }
        "10.131.13.0" { 
            $AutotaskId = "192-"
        }
        "10.131.11.0" { 
            $AutotaskId = "194-"
        }
        "10.131.4.0" { 
            $AutotaskId = "195-"
        }
        "10.131.5.0" { 
            $AutotaskId = "196-"
        }
        "10.10.11.0" { 
            $AutotaskId = "197-"
        }
        "10.131.6.0" { 
            $AutotaskId = "198-"
        }
        Default { 
            $AutotaskId = ""
        }
    }

    $DeviceRole = "GU-"

    $NewDeviceName = $AutotaskId + $DeviceRole + $SerialNumber

 if(($DeviceName -ne $NewDeviceName) -and ($AutotaskId -ne "")) {
        Write-Host "Renaming $DeviceName to $NewDeviceName."
        Set-MgDeviceManagementManagedDeviceName -ManagedDeviceId $WindowsDevice.Id -DeviceName $NewDeviceName
    }
}

By renaming the device, it allowed us to create dynamic groups in Azure for each location code. If a user moves a device to another location, we capture it since the script runs weekly.

In addition, we have another script running monthly to capture the dynamic group member count and push it to the client contract in Autotask.

This is all just something to think about. If i can avoid extra manual labor, I’m going to.

1 Like
7

Very nice, thanks! I can think of a few uses for that actually :slight_smile: Much appreciated!

8

I would prefer it picking up a tag for location so it can remain a cross-tenant deployment.
The best thing would be if we could replicate locations from Ninja to Immy or just Immy in general but Immy doesn’t have a locations feature under each tenant as of today.