Talk:Group Policy

From Wikipedia, the free encyclopedia

	This article is part of WikiProject Microsoft Windows, a WikiProject devoted to maintaining and improving the informative value and quality of Wikipedia's many Microsoft Windows articles.
B	This article has been rated as B-Class on the assessment scale.
High	This article has been rated as high-importance on WikiProject Microsoft Windows's importance scale.

The "Best Practices for Designing Group Policies" section either needs to be dumped or rewritten. Part of the section deals with the author's idea of "Best Practice" while the rest alludes to where (and what) GPOs can be applied but omits to state why. No mention is made of GPOs working at a per attribute level.

RyanG

[edit] Best practice section deleted from main article

Best Practices for Designing Group Policies

1. Write the policy as high as possible. (at Domain or OU level)
2. Work with e-Security to define policy. Security policies defined at highest level.
3. Define Generic Policies as high as possible.
4. The policies do not affect default administrator accounts
5. Block inheritance at OU if needed. Can be Enforced at parent level. Enforced policies can not be blocked.
6. Higher Policy in list takes precedence. (order in the list is important)
7. Deny Apply Group Policy at Group level for IT Management Team
8. Staging environment for Group Policies. Good Idea!
9. You can NOT write policy at:
   • Built in
   • Computers
   • Users
   • Groups
10. You CAN write policies at:
    • OU Level
11. Create an OU Design that requires least GPOs.
12. Site Level GPOs requires enterprise administrations permissions.
13. Domain Level GPOs requires domain administrations permissions.
14. OU Level GPOs requires appropriate permissions. Delegation of Administration.
15. GPOs take effect in the following order:
    1. Local Machine
    2. Sites
    3. Domain
    4. OU
16. Machine Based Policy take effect on Reboot
17. User Based Policy take effect on Logon

RyanG 14:52, 25 August 2005 (UTC)

[edit] Disadvantages

I think we should talk about the disadvange of using it, which is that if the user logs in and disconnects from the network some of the group policys don't load. —Preceding unsigned comment added by 219.88.3.50 (talk) 03:28, 20 October 2007 (UTC)

[edit] Are you sure?

Someone recently added this:

Security A problem with the per-user policies is that they're only enforced voluntarily by the targeted applications. A malvolent user can interfere with the application that it cannot successfully read its Group Policy settings (thus enforcing potentially lower security defaults) or eve return arbitrary values. The user can also create a copy of the application at a writable location, and modify it such that it ignores the settings. One should rather see it that the Group Policy helps the user provide some safe defaults to help him enforcing security for himself.

However, many group policy settings apply to windows itself, and cannot be over-ridden. Most policies are things such as disabling registry editing, disallowing the task manager, etc. This type of policy typically cannot be overcome. What do others think? --Tech Nerd 01:55, 6 November 2007 (UTC)

• if you create a copy of cmd.exe or taskmgr.exe that don't check to see if they are disabled, they will run fine. they are referring to the fact that even windows apps must enforce the settings that apply to them, not that the system will somehow stop them. PidGin128 from 149.168.240.7 (talk) 14:45, 2 June 2008 (UTC)