Having a global deployment to add an app (TeamViewer host), then a tenant deployment to not add the app but a tenant deployment to add the full version (TeamViewer) then a tag deployment to not add TeamViewer then a tag deployment to add TeamViewer Host it mess and a pain
Adding in an exclude would allows us to do a global deployment of TeamViewer Host excluding Tag “FullVer” then add a deployment for just that tag.
So it’s simpler to have 3 deployments instead of 3 deployments? I can’t say I follow the logic here.
Current:
Global Deployment
Plus a tenant deployment to ignore
Plus a tenant deployment to install the desired version
Plus a deployment to exclude the tenant version to a specific tag
Plus a deployment to deploy the global deployment to the specified tag
vs
Proposed:
Global deployment that affects all excluding tag
Plus a deployment for that tag
Global Deployment of what?
Tenant deployment to ignore what? I assume the cross tenant one (if that’s what you mean by global)
You don’t need an ignore deployment if you create a tenant specific one to install a specific version, that will override the cross tenant one already.
Plus a deployment to exclude the tenant version to a specific tag? Not sure what that means.
Plus a deployment to deploy the global deployment to the specified tag? Not sure what this means either.
Mixing inclusions with exclusions is likely to create more confusion (and bugs/resolution issues). I think this is one of those things that @DarrenDK would call an anti-pattern.
Without really understanding what you are looking for, I’m going out on a limb and saying that I think a tenant level tag would probably simplify your deployment structure, but I’m not sure that’s even necessary–it just sounds (to me) like you’re creating ignore deployments unnecessarily.
So we use 2 versions of TeamViewer, these are 2 independent apps not different versions
We use the Host installer, and the Full installer
All clients must have the Host installer,
So cross tenant deployment of host installer
Internal staff must not have the Host installer
so tenant level ignore deployment
Internal staff must have the Full installer
So a tenant level deployment of the Full installer
But a subset of machines (Management machines) must not have the Full installer
so a group level deployment to ignore the full installer
But the subset of machines above must have the Host installer
So a group level deployment to install the Host installer
If I can exclude i can say
Cross tenant install the Host installer
Exclude Group/Tag X
Group level Full installer for group/tag X
Keep in mind installing the Host version removed the Full version and the Full version removes the Host Version
Ok, definitely easier to understand now.
However, it looks like you’re only needing to override the cross tenant deployment for your own internal systems, as opposed to every single tenant–yes?
What I’m wondering here is if prerequisites will simplify this. The Host Installer should have a prerequisite to uninstall the Full installer, and the Full Installer should have a prerequisite to uninstall the Host Installer.
So it sounds like what might work for you is:
- Keep the cross tenant deployment you have for the host installer
- Create a tenant level deployment for the full installer
- Create a tenant level deployment targeting management for the host installer (which should override #2)
…so I think you can get what you’re after with those prerequisites and this set of deployments–and would also prevent the full and host installers from being installed simultaneously anywhere, ever.
Unfortunately due to the different deployments, the tenant level does not override the cross-tenant deployment. thus we need the 2 ignore deployments.
…and you’ve set up the prerequisites?
Yes, unfortunately, the prerequisites are causing the issue
as they are separate deployments the method you suggested uninstalls TeamViewer full, then installs the Host version
Then when the full app runs it removes the host and installs the full again
not exactly ideal
One thing I did notice is that you can query the tags with Get-ImmyComputer, though strangely enough they’re not included by default, so you’d need to add -IncludeTags param. You could make a filter script that way?
Aside from that, while it’s possible there’s a better way than Exclude tag, it’s still a fairly intuitive way to get more granular control on deployment logic. I say anything that can potentially minimize the number of separate deployment schemas is something I’d be in favor of. More flexibility in how tags are assigned and used would be greatly appreciated by myself at least.
@Benjamin_Danet
I ended up putting together a filterscript for this.
Get-ImmyComputer -IncludeTags | ? {$_.OperatingSystemName -NotMatch 'Server'} | ? {[String]$_.Tags -NotMatch 'YOUR-TAG-HERE'}
You should test it first, because it’s trial-and-error rather than knowing how to implement it but I was able to get the desired effect in an easy one-liner. It’s a bit slapdash with excluding servers, and converting the propertylist to a string because I didn’t have a case in my env that would have an issue with it.
1 Like
Being able to set an exclude tag condition per deployment would be great.