Talk:Group Policy

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

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)

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)

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)

Equivalent technologies?

Do other operating systems have something equivalent, and if so, which? --MushroomCloud (talk) 06:48, 21 December 2009 (UTC)

Mechanisms

I would love to know how group policies actually work under Windows. All I know is that "The Group Policy client operates on a "pull" model - every so often...it will collect the list of GPOs appropriate to the machine and logged on user (if any)" and that .pol files are or were once relevant somehow. I have no idea of what process under windows is responsible for downloading policy, the procedure that it uses to download policy and its position in the login sequence. It has to work over smb somehow...

I am looking around and if I find anything then I'll write something brief with references. If anyone actually knows what's going on here then your contributions will be greatly appreciated. 75.152.165.152 (talk) 22:48, 21 February 2010 (UTC)

Delegation

I think the 'delegation' part in the Overview may be mistaken. It's not about controlling the scope of the group policy will apply, it's about who can be trusted with creating or editing group policies. See http://support.microsoft.com/kb/221577 . SyP (talk) 18:15, 25 April 2010 (UTC)

Security Section

This section makes no sences to me... i think this section should be deleted. — Preceding unsigned comment added by Alanburchill (talk • contribs) 08:28, 15 February 2011 (UTC)

Group Policy Refresh

"Since Windows XP, a refresh of the group policy can be manually initiated by the user using the "gpupdate" command from a command prompt.[1]"

Windows 2000 also had the secedit command to force a refresh. SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE SECEDIT /REFRESHPOLICY USER_POLICY /ENFORCE

http://support.microsoft.com/kb/227302 —Preceding unsigned comment added by 199.16.223.2 (talk) 23:08, 15 April 2011 (UTC)

Group Policy Refresh

"Since Windows XP, a refresh of the group policy can be manually initiated by the user using the "gpupdate" command from a command prompt.[1]"

Windows 2000 also had the secedit command to force a refresh. SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE SECEDIT /REFRESHPOLICY USER_POLICY /ENFORCE

http://support.microsoft.com/kb/227302 —Preceding unsigned comment added by 199.16.223.2 (talk) 23:10, 15 April 2011 (UTC)

Minimum windows version?

I recall quite fondly that even Windows 95 supported group policies. They even included the editor on the retail install cd. And it was perfectly able to target both computers and users. This seems to contradict a lot of the claims in the article.--Henke37 (talk) 17:16, 1 February 2019 (UTC)