config profiles "fragmentation"? yay or nay?

[MaxMorsia]

Hello all,

We have two different device groups to which we want to deploy slightly different configuration profiles in endpoint. These configuration profiles are mostly about the device restrictions - password module. Basically, the password requirements are the same, but for practical reasons we need to implement different screen lock times for the two groups. Logically, it would make sense to create a profile with the common settings and deploy it to both groups, and then two additional profiles where the only setting is the different screen lock inactivity periods. This way any change made on the password requirement should affect both groups at the same time. I'm not sure anyway if this is considered best practice, or if it'd be better to store two complete password restrictions profiles for both groups. As it is right now (with the common settings in one profile and the two screen lock times in different additional profiles) I'm not experiencing any conflict, so it seems the rules are correctly deployed, but I'm not so sure if this is the way Endpoint would handle this scenario in the best way possible. Any suggestion?

[#2]

There is intelligent life at Microsoft Intune? The reason I don't have all of my devices enrolled is because I am not very smart! The days go by without the security that my licensing cover are my responsibility!

[#3 · Accepted solution]

@MaxMorsia 

The approach you describe sounds okay, since you're doing it with deliberate intent per the group requirements around screen lock/password. A new admin might not see the correlation right off the bat and wonder why there's multiple policies, until it's explained or documented properly; that's the only aspect which might be unclear until the policy settings are examined to identify the differences. As long as changes aren't made to the ones "Not Configured" which would introduce a conflict, it's fine.

In contrast, doing two fully complete policy sets solves for the above problem in that it's clearer at first glance and no overlap, but at the tradeoff of being a bit redundant. I would choose this approach if the expectation is that some other admin will be managing/maintaining it in the future, because they might not be aware of the subtle logic behind the other approach. But if it's just you, either is valid.

Please like or mark this thread as answered if it's helpful, thanks!

[#4]

In the end I went for the complete policy sets for clarity's sake. After a while, following the former approach, the config profiles where too "granular" and difficult to follow, as you said.

[#5]

My devices vary some antiquated some not so much to throw a net of a policy in some situations may cause more problems than the policy was intended to prevent to strike a balance across devices it seems a challenge