Please confirm:
Problem Statement
Currently in the Hudu integration it supports only a single asset layout for M365 devices when syncing.
However, we have both "Windows Laptops" and "Windows Desktops due to the NinjaOne integration loop with Halo/Hudu. For reference this comes from these settings here. If you use nodeClass everything comes in as WINDOWS_WORKSTATION which is pretty ugly, whereas nodeRole imports based on the Ninja device role which is useful when we have vendors supplying security systems which run on a desktop OS, but from a policy/management perspective need to be treated as a "server". It's also quite common in medical practices when there are multiple different specialists, we have routinely taken on new customer sites to find a row of desktop machines one for each specialist running a desktop OS and their practice management software.
But back to the topic, using the nodeRole makes logical sense to how things are treated, both from a policy/monitoring perspective, but also for billing purposes as regardless of OS, its role determines its billing. However, that means for the desktop/laptops it creates separate asset layouts/asset types.
It would be ideal if we could select multiple asset layouts to search and match against.
Benefits for MSPs
The benefit is that you can have multiple asset layouts and still sync CIPP data against them, without this then we have to pick one so data gets missed.
Value or Importance
It's a balance, you could argue it's critical as it doesn't work without it, however we can get the data in other ways so for us it would be more a nice to have, we just don't use that functionality to sync that data from CIPP -> Hudu. The value would be consistency, bitlocker/laps data would be nice to have within Hudu, but it can be extracted in other ways.
PowerShell Commands (Optional)
No response
Please confirm:
Problem Statement
Currently in the Hudu integration it supports only a single asset layout for M365 devices when syncing.
However, we have both "Windows Laptops" and "Windows Desktops due to the NinjaOne integration loop with Halo/Hudu. For reference this comes from these settings here. If you use nodeClass everything comes in as WINDOWS_WORKSTATION which is pretty ugly, whereas nodeRole imports based on the Ninja device role which is useful when we have vendors supplying security systems which run on a desktop OS, but from a policy/management perspective need to be treated as a "server". It's also quite common in medical practices when there are multiple different specialists, we have routinely taken on new customer sites to find a row of desktop machines one for each specialist running a desktop OS and their practice management software.
But back to the topic, using the nodeRole makes logical sense to how things are treated, both from a policy/monitoring perspective, but also for billing purposes as regardless of OS, its role determines its billing. However, that means for the desktop/laptops it creates separate asset layouts/asset types.
It would be ideal if we could select multiple asset layouts to search and match against.
Benefits for MSPs
The benefit is that you can have multiple asset layouts and still sync CIPP data against them, without this then we have to pick one so data gets missed.
Value or Importance
It's a balance, you could argue it's critical as it doesn't work without it, however we can get the data in other ways so for us it would be more a nice to have, we just don't use that functionality to sync that data from CIPP -> Hudu. The value would be consistency, bitlocker/laps data would be nice to have within Hudu, but it can be extracted in other ways.
PowerShell Commands (Optional)
No response