Currently it is not possible to select multiple tenants when creating licenses, but where an organasation has subsidiaries with their own tenants it is required.
Funny you should use Foxit as the example here as we include it in our Managed Services stack. What we do is add it as a product on the customer’s CW Manage agreement and make one deployment against that. The feature I thought you were going to ask for would be if individual tenants had different licenses, the deployment would be able to auto-select it based on the tenant.
I’m actually considering removing the license feature all together and replace it with parameters.
We have a huge overhaul in progress that will allow you to define all your parameters in the param() and dynamicparameter{} areas of the functions for tasks which exposes all of PowerShell’s underlying parameter validation functionality. Along with this, we plan to move parameters into JSON objects on the deployment itself, however, it might be smarter to put them in their own table so the same parameters can be linked to multiple deployments. I just sort of feel like it creates confusion and we should instead make it easier to assign deployments to multiple tenants.
Every time I’ve gone to use the License feature it doesn’t seem to be available or work right, but it’s also annoying to have to separately keep track of parameters like SentinelOne API keys and such and track them down to create new deployments for a different tenant though it’s a global key, plus it would be nice (ideal) to have a way to store things like API keys centrally in a way that not all users could access (display/copy easily/see visually, obviously not a hard security boundary) but could be referenced for use in deployments.
It sounds like what you’re suggesting might be moving at least somewhat towards this in some way? I like the license feature being set separately from the deployments, but having cross-tenant and central “credential/API” store areas would make the concept more useful even if not called “licensing” as its current form.
For SentinelOne you only need one deployment. Is there is a reason you are making multiple deployments?
Well, we’re moving towards a bigger rollout with SentinelOne and Immy having just switched out of an integrated product we had no admin S1 access to as of Nov 30. So I don’t have the details of what a full rollout would look like with Immy, we’ve only done spot deployments for clients where we’re doing onboarding with Immy. So maybe I’m missing something–we’d have some tenants where we wouldn’t deploy S1 due to alternate solutions being place, and even with that, we may have some co-managed clients where the client shouldn’t be able to review the deployment or may want to customize it…haven’t gotten here due to the N-central beta tenant jumping stuff but we have some clients we’ll likely be doing co-managed with, and I haven’t yet seen how the permissions/visibility works, admittedly.
They recommended way to deploy SentinelOne would be to create a single cross tenant deployment that links to your PSA in such a way that it deploys SentinelOne to customers paying you for SentinelOne.
Hopefully we can get the N-Central agent hopping thing resolved soon. We had a call with them yesterday but it wasn’t a technical call. We are hoping to have a path forward next week.