Following on from some earlier posts looking at the management process in both Microsoft InTune and Google Workspace it’s worth having a closer look at user and device policies because the models diverge quite a bit at this point.
In Google Workspace there is a clear division between a policy that applies to a device and one that affects the user experience. In fact, other than a few examples I can think of the two policy sets are completely unique.
If you then move into the Microsoft space this division breaks down entirely. Here you have a single unified policy set which can be applied at either the device or user level.
To give an example, using the Microsoft approach you are able to set a policy which controls an aspect of the user environment and apply it at the device level. The result will be that the feature will be set regardless of which user logs on.
Using Google Workspace that's not possible. You can’t set a policy that controls the user experience and apply it to a specific Chromebook.
Google Workspace has a kiosk mode which does something similar but this does not apply to authenticated user sessions.
Although this sounds a little restrictive it does make things easier to maintain and troubleshoot. You never have to check if a policy is being set by the device or the user object and there is never any conflict resolution.
Not surprisingly Microsoft suggests an simple approach to user and device policy.
“If you want to apply settings on a device, regardless of who's signed in, then assign your profiles to a devices group. Settings applied to device groups always go with the device, not the user.”
“Profile settings applied to user groups always go with the user, and go with the user when signed in to their many devices.”
The difference between the two platforms is that while Google Workspace imposes these rules, with Microsoft it's just a recommendation. Microsoft provides flexibility but this comes with added responsibility and complexity.
A second major difference is that, in general, Microsoft policies are applied through a group structure You can create a policy and then apply it to single or multiple groups and those groups can be nested. To also have the ability to create groups that contain users - and groups that contain devices and apply both to the same policy set. One last level of complexity is that groups can be be marked as either applied or excluded for each policy - with exclusion taking precedent,
Now just because you can do these things doesn’t mean you should and in fact there are good reasons why you really shouldn’t.
Again Microsoft best practice strongly recommends you do not mix grants and exclusions using user and devices groups as the results “may not be what you want or expect”. They provide a useful table which is really no more than common sense.
Keeping it simple and granular is going to be the best approach working with Microsoft policies.
For both users and devices Google Workspace uses a hierarchy of organisational units to apply settings. Policy is determined but the object's position in the tree and the inheritance at that level. The major advantage of this approach is its simplicity and ease of troubleshooting but it can be difficult to incorporate exceptions to the rule. For this reason Workspace is stealing a page from Microsoft and incorporating the concept of group exclusion. A user set can have a policy applied based on the location in the OU tree but the setting can be overridden by group membership.
Typically, you would apply services settings to OU's and then make exceptions for some users. For example, you can restrict YouTube content for accounts but let some groups view all videos or approve videos. In all cases the policy set by the groups overrides the policy set at the OU.
Not all services allow this function. The ones most commonly used by education include ;
- Directory (Profile editing)
- Calendar
- Currents
- Drive
- GMail
- Google Meet
- YouTube
Since Google Workspace has no concept of a device group these actions apply to users only.
Lastly both platforms have a different way of handling policy negation.
Google Workspace administrators are used to working with policies that have distinct values (ON/OFF) with each setting having a default value. Also since each device or user object must exist somewhere in the OU tree every policy has a setting. The amalgamation of all the settings defines the profile.
This isn’t the case in the Microsoft world. The policy set is a variable array with elements being added or removed as an assignment moves in or out of scope. The challenge occurs when a policy sets a value to ON but then moves out of scope without another value being explicitly set.
Does the values return to the original setting, a default or remain the same ?
The answer is “it depends”.
The settings are based on Configuration Service Providers (CSP) and each CSP can handle profile removal differently. Some might revert to default values, others do nothing. Microsoft's advice is to work explicitly with each value that needs precise control.
For instance if you have restricted a user from a desktop service, simply removing the user group from the policy scope may not be enough to grant access,
To change a setting to a different value, create a new profile, configure the setting to Not configured, and assign the profile to the device. Once applied to the device, users should have control over the service,
Microsoft InTune and Google Workspace, two management models, each with their own strengths and weaknesses. Not better, just different.
