In Sri Lanka, there is a common saying: eating curd from a knife. Curd with honey is amazing, but if you have to eat it using a sharpened knife, there is a risk you may cut your tongue if you're not careful. But it's still worth taking the risk (if you ever tasted curd and honey before). Group policies are also like that; they can do so many things but only if you use them correctly. In the Active Directory environment, Group Policy-related issues are the most painful and time-consuming task as there are so many things that can go wrong.

Here, I have listed a few tips that will be useful for Group Policy designing:

• Identify the best place to link the Group Policy: Group Policy can be linked to the site, domain, or OU. Organizations have different Group Policy requirements that can also map with the aforementioned components. It is important to understand the best place in the hierarchy to publish each Group Policy setting. This will prevent repetition and Group Policy conflicts. As an example, password complexity settings are common for all the objects under the domain, so the best place to link the policy for the password setting is the domain root, not the OU.

• Standardize settings: Today, infrastructure requirements are complex. Each business unit has its own operation and security requirements to address group policies. When designing group policies, always try to summarize the changes as much as possible. If two business units have almost the same user settings requirements, discuss it with the relevant authorized people (line manager, team leads, and so on) and try to use the standard settings. This will allow you to use one Group Policy and link it to two business units instead of creating two separate group policies. Always try to reduce the number of group policies that will be used in the system as when the number of group policies increases, it also increases the time to process during the login process.

• Use meaningful names: This is a small suggestion, but I have seen people use Group Policy with names that don't explain anything. In such a scenario, when you go for troubleshooting, it can take an awful amount of time to find the relevant Group Policy. Make sure that you name the Group Policy to reflect the settings in there. It doesn't need to have details, but at least have something that you and your colleagues can understand.

• Avoid mixing user settings and computer settings: Group Policy has two main configuration sets that will apply to users and computers. Always try to avoid mixing these settings in the same Group Policy. Try to use separate group policies for computer settings and user settings. This will make it easy to organize policies. After that, disable the unused configuration section in the Group Policy to avoid processing. This can be done using GPMC:

• Use Group Policy enforcing and block inheritance appropriately: These features are a good way to manage the default Group Policy inheritance, but use it carefully as this can prevent users/system from applying critical policy settings applied from the top of the hierarchy. Because most policy settings come from the domain level, parent OU levels are related to security- and system-related settings. In the same way, by enforcing policies, you may enforce settings to users and computers that should not be a target. Therefore, always measure the impact before using enforce or blocking inheritance features.

• Do not edit default policies: There are two default group policies: Default Domain Policy and Default Domain Controllers Policy. It is highly recommended that you not use these to publish the Group Policy settings. These can be used as the baseline when you design the group policies and also allows you to revert to the original settings with minimum effect. These can also be used as a reference to troubleshoot inheritance issues and replication issues.

• Be careful with using loopback processing: Lots of issues related to loopback processing are due to lack of knowledge, especially related to replace and merge modes. In this chapter, before I explain both of these modes, we will use an example that you can use as a reference. If you are enabling loopback processing, always use separate Group Policy and name it correctly so that everyone understands it when it comes to troubleshooting. My recommendation is that you use it in a situation where you can use the replace mode. The merge mode can create lots of hassles with combined group policies plus conflicted settings.

• Win or lose: Earlier in this chapter, I explained which policy settings will win when there is a settings conflict. But in theory, there should not be any conflicts at all if the design is correctly done. Therefore, in design, always avoid repeating values in a hierarchical structure. If different values are used for the same setting, use filtering options and block inheritance to prevent the policy conflicts.

• Housekeeping: Last but not least, it is important that you review the group policies periodically and remove the policies that have not been used. Also, remove the legacy policy settings if they have been replaced by new policies or methods. Audit and make sure that the hierarchical order is maintained and objects are getting the expected group policies applied to them.