Overview Policy precedence was explained In a previous Wiki article, Domino Policy Precedence Explained. But one aspect of Domino Policies was not covered, namely the How To Apply (HTA) feature. Whereas policy precedence determines how the settings from several policies are combined, the How To ...

Overview In Domino 8.5 two new features were added that affect the policy space, Dynamic Polices and Home Server groups. While Home Server groups can be used independently from dynamic policies, they can be used together to make it even easier to manage user settings. In this example, Message ...

How the new Dynamic Group Policies can reduce your administration workload

This brief article will highlight the benefits of using the new Dynamic
Group Policies (DGP) in Domino 8.5. It will do this by showing the
issues an administrator would have to have dealt with pre-8.5 and how DGP
addresses those issues.

Pre-DGP

Prior to 8.5 there were only two kinds of policies: organizational and
explicit. The former applied to everyone in an organization and so
were pretty simple to administer. You just created it, removed it,
or modified it. The latter type, explicit policies, had a lot more
administrator involvement because they had to be added or removed from
individual person documents. There were 5 ways of doing this:
1) Edit the person document directly and add/remove/change
the assigned policy.
2) Select one or more person documents in the People view
of the directory in the admin client and then right clicking and picking
Assign Policy tool.
3) Select one or more person documents in the People view
of the directory in the admin client and select Tools->People->Assign
Policy.
4) Select one or more group documents in the Groups view
of the directory in the admin client and then right clicking and picking
Assign Policy tool.
5) Select one or more group documents in the Groups view
of the directory in the admin client and select Tools->Groups->Assign
Policy.

You could have created your own tool or agents to set the Policy field
as well, but only the above mentioned methods will be addressed here.

The first three options are functionally the same. The problem is
that say you want to change a policy that you've given to everyone on a
certain mail server. You have to find out everyone who has mail on
that server and either select all of them and then do option 2 or 3 above.
Or you have to change each one individually as in option 1. In
both cases you have to hope that you don't miss someone!

But let's say that you have a group defined for all of the users on that
mail server, "Corp Mail Server 1". So you could use options
4 or 5 to apply the policy. But wait, what happens if you later add
someone to the group? Since they weren't there when you applied the
policy initially, they won't get the policy. You would have to re-apply
the policy to the whole group. Similarly, if you remove that person
from the group, they would still have the policy assigned. In this
case, re-applying the policy won't help you, you have to clear the policy
out of their person document via options 1, 2, or 3. And if the
group, "Corp Mail Server 1" contained subgroups, you would have
do to this step for everyone in any of the subgroup(s). That would
be a lot of manual work.

Another limitation is that a person can only have one explicit policy assigned
to them in their person document. So let's say that you had one explicit
policy that dealt with only security settings and another explicit policy
that had only desktop settings. Since a user can only have one explicit
policy at a time, if you wanted a user to have both settings you would
have to create a third policy that combined the security settings of the
former with the desktop settings of the latter. In effect, you would
have to have an explicit policy for every combination of settings that
you wanted. This would result in a proliferation of policies.

DGP to the rescue!

In the first three cases above, instead of a user being assigned a policy,
the policy contains the list of users to whom it applies. You can
easily add or remove people right from one place, the policy. You
don't have to open up multiple documents. Additionally, if you use
the Home Mail server auto-populated group option you wouldn't have to figure
out who is on the mail server at all!

But where DGP really helps of course is with dealing with users on a group
basis. If a person is removed from a group, they will automatically
no longer have that policy assigned to them. Similarly, if they are
added to a group, they will get the policy for that group. And if
subgroups are involved, you can quickly remove all of the people from a
group without having to worry about what subgroups that they may additionally
contain.

Additionally, since a user can be in more than one group at a time you
could have one group called "Security Settings group" and another
called "Desktop Settings group" each which are assigned to Security
Policy and Desktop Policy respectively. The user could be added to
both groups and now will receive both of those settings since they will
be merged into their final effective policy. If more than one group
has a particular setting, then precedence will come into play and that
is described in another Wiki article here domino-policy-precedence-explained
So creating a third policy wouldn't be needed any longer!

Now it might be argued that instead of creating multiple policy documents,
the effort has been replaced with creating multiple group documents. But
the difference is that when you want to make a change you would only have
to potentially change 1 group document instead of having to change multiple
person documents. An additional benefit is that when the group documents
themselves are automatically maintained either through Home Server groups
or other group management systems, two layers of administrative headaches
have been removed. Say for example that you have a company
NSF application where you keep track of employees that are on vacation.
In such an application, when a person logs their vacation time they
will automatically be added to a group of "Out of Office" people.
That group could then be used to control some mail settings that
could be relaxed during the time they were away.

Conclusion

Dynamic Group Policies are a great way to cut down on the workload of the
administrator. And they can also be used to provide more flexibility
than explicit policies alone. When combined with Home Server groups
or other methods where groups are automatically generated, an administrator's
workload can be reduced even further. So start using Dynamic Group
Policies today and reduce your Total Cost of Ownership!