Picture the scene, you have a large organisation (or possibly multiple large organisations) and many little silos within, each has their own IT department and traditionally they all did their own thing with imaging, app deployment, probably via a delegated OU in active directory. Now you want to go cloud native, but the idea of setting up multiple tenants is keeping you up at night.
Fortunately, there is an answer within Intune which will keep everyone happy, you can keep one tenant and central control with fixed baselines which only you can access, but your other departments can have their own config settings as well.
There are two kep components to this from an admin side and these are Group Tags and Scope Tags. I’ll also briefly cover Policy Sets which can be useful when looking at the user deployment side.
Group Tags
So, the first issue you have come across is the basic Windows deployment. You want to use Autopilot (obviously), but you also want the different departments to have a different naming convention (so you can easily check which machine is running Steam) and they may also have a different set of core apps you need installing prior to login.
Traditionally when importing a device into Autopilot, you would probably just grab the hardware hash via the excellent get-windowsautopilotinfo.ps1 script and either export to CSV and upload, or just go straight for the -online parameter.
All we need to do when working with multiple ‘builds’ is to append the -GROUPTAG parameter to the end, for example
get-windowsautopilotinfo.ps1 -grouptag Department1 -online
It is worth noting at this point that if you are using a Dynamic autopilot Azure AD group on the ZTID tag:
(device.devicePhysicalIDs -any (_ -startsWith "[ZTDid]"))
This will also catch anything with a group tag. You can either add an exclusion on your specific tag:
(device.devicePhysicalIDs -any (_ -startsWith "[ZTDid]")) -and -not (device.devicePhysicalIDs -any (_ -eq "[OrderID]:Department1"))
Which works fine when the GroupTag is by exception, but if you’re working with multiple departments, it’s probably best to ditch this catch all completely and just have a group for each one.
Obviously we’re now going to need a dynamic group for these devices too:
(device.devicePhysicalIds -any (_ -eq "[OrderID]:Department1"))
Then just assign the Autopilot Profile and ESP to this new group.
So, that’s the initial ‘build’ sorted, but what about the policies on top? On to
Scope Tags
You’ll probably notice when configuring a policy that one of the menu options is for scope tags and Default is always there (and I imagine you just click next and don’t think much of it)
Well, scope tags are an excellent way of delegating control of policies and far too unloved!
Firstly though, setting them up is a little bit hidden!
In Endpoint Manager, navigate to Tenant Admin – Roles and you’ll find Scope Tags hiding here:
Generally, I use the Default one for any baseline policies, the sort which everyone gets whether they like it or not.
Now, we can create a new tag for Department1:
Give it a name:
Now, we can assign it to the Entra ID Device group we created earlier to also help with delegation, this will give the admins of Department1 full control over their devices only:
Ok, so that’s the first tag created, next step is to assign it to a policy which can be delegated:
I’d always suggest leaving Default so you can see everything in your environment and edit if needed.
Finally, we need to give the Department1 IT Admins access to their section
Back to Tenant Admin – Roles and then either copy one of the built-in roles, or create your own from scratch and give it ONLY the new scope tag:
This will give them access to their devices and policies, but nothing outside of that. If they need a new policy creating, they will need to request a blank template to be created with the approprate Scope Tag assigned.
There we have it, a centrally managed Intune environment but with delegated access as required.
4 thoughts on “Intune Group Tags, Scope Tags – What are they and why do I need them?”