Logo
PREGNANCY
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
 
 
Windows Vista

Group Policy Object Overview (part 1) - Building a Local Computer Policy & The Domain Member Computer

3/14/2011 10:02:10 PM
Policies are the way that computers are managed, either standalone computers or computers in the enterprise. Policies establish the vast majority of the configuration settings that control how the computer boots up and then how your desktop environment is constructed when you log on.

The Standalone Computer

Each computer has a Local Computer Policy, or LCP (also referred to as the Local GPO or LGPO), that is made up of many configuration settings on the various configuration dialog boxes throughout the user interface, as well as numerous settings that are configurable only in a Microsoft Management Console (MMC) called the Local Computer Policy. This policy is stored in the Registry on the computer’s hard drive and is applied every time the computer is booted up. This computer configuration from the Local Computer Policy gets read into random access memory (RAM) on the computer. Think of this RAM copy of the Registry as the live, awake brain of the computer when it is booted up. This RAM copy of computer settings from the Registry is in place when you are presented with the Windows Graphical Identification aNd Authentication (GINA) dialog box.

Further configuration for the desktop environment is controlled by configuration parameters stored within your user profile in a file called NTUSER.DAT.NTUSER.DAT gets read into RAM from your profile folder when you successfully log on to the computer. As you make changes to your desktop environment, like the desktop wallpaper or items on the Start menu, these changes get recorded in the RAM copy of NTUSER.DAT. When you log off, by default, the operating system saves these changes into your profile. This file is the primary source of the configuration parameters that define your desktop environment.

The first time you log on to a computer, the operating system copies a read-only and hidden folder under C:\Users called \Default to a new folder under C:\Users and renames the new folder with your logon name. Within that folder is the file named NTUSER.DAT. This becomes your user profile on this specific computer. After that first logon on a given computer, now that you have an existing profile, this existing copy of NTUSER.DAT is the one that gets read into RAM for your user profile.

To summarize, two components define a desktop environment on a standalone computer (not participating within an Active Directory environment): the configuration parameters in the Local Computer Policy and the configuration parameters in your user profile. They get applied in that order.

The LCP can be accessed on a Windows Vista computer by building it into a new MMC.

Building a Local Computer Policy (LCP)

To build the Local Computer Policy (LCP) MMC, follow these steps:

1.
Click Start > Run, type MMC, and click OK. (You can also use Start > Start Search > MMC and then press Enter.)

2.
From the menu, select File > Add / Remove Snap-in.

3.
Select Group Policy Object snap-in and click Add.

4.
Accept the Group Policy Object for the Local Computer by clicking Finish.

5.
Click OK.

6.
From the menu, select File > Save As.

7.
Type LCP.msc and save the MMC either on the desktop or in Administrative Tools.

The Domain Member Computer

Back in the old days of the Windows NT domain and Windows 95 clients, Microsoft used something called System Policies, built using a tool called the System Policy Editor, to manage and configure these down-level computers. These System Policies would “tattoo” the Registry of the local box, actually writing settings to the Registry files on the local hard drive. If you wanted to remove policy settings from the computers, you had to write a new System Policy that would actually reverse the settings from the policy that was being removed.

When Windows 2000 was released, Microsoft implemented a whole new generation of policies and completely overhauled how they were applied on computers. These policies were improved yet again with the release of Windows XP, Windows Server 2003, and now again with Windows Vista. These new policies are called Group Policy Objects, or GPOs, and they exist in the Active Directory in an enterprise environment. These policies get applied to the computer over the top of the Local Computer Policy and your user profile settings to provide enterprise administrative dominance over the local configuration settings.

Note

GPOs Apply to Domain Members Only Keep in mind that GPOs affect only computers and users that are members of an Active Directory domain. If the computer and user are not members of an AD domain, only the Local Computer Policy and the user’s profile get applied to the user’s desktop session. No GPOs. If you apply a GPO in AD and don’t see the effects on the computer and user, double-check to be sure that the computer and user are members of the AD domain.


These new policies do not affect the configuration files on the hard drive (for the most part), so they do not “tattoo” the computer. Rather, as these new policies get applied, they modify the copy of the Registry (computer) and the profile (user) that has been read into RAM on the computer during the initial bootup and then the user logon for the current session. These modifications to settings do not get written back to the hard drive copies of the configuration files. Remember that this RAM copy is the actual functional copy that is being used to control and configure the user’s current session.

L-S-D-OU-OU-OU

Active Directory (AD) is a database and a collection of directory services that support the database and the network operating system. AD is created by configuring one or more domain controllers on a network. AD utilizes four types of containers to store and organize AD objects, like computers and users:

  • Forests

  • Sites

  • Domains

  • Organizational Units

You can apply GPOs to sites, domains, and Organizational Units.

AD Forest

The AD forest is one or more AD domains that share a common schema. The schema is the structure of the AD database—not the data within the database, just the structure. The forest is created when you run DCPromo on a server to install your first domain controller in the first domain in the forest. This first domain is referred to as the forest root domain. The name of this forest root domain also is the name of the forest. All domains within the forest are trusted by and trusting of all other domains within the forest. Therefore, since members of your forest are, by default, all trusted and trusting, a lack of trust with some new domain indicates the need to generate a second forest, or create the new, untrusted domain in a different, existing forest. Forests are logical containers and have no real connection to any physical location, other than you must place your domain controllers somewhere. GPOs cannot be linked to the forest.

AD Sites

AD sites are created in AD once the forest is established and are defined as a collection of well-connected segments, where the bandwidth is at least local area network (LAN) speed. LAN speed is currently considered to be 10Mbps or greater. Any network link between segments that drops below LAN speed is defined as a boundary of the site and indicates the need for the creation of an additional site. Because sites are defined by physical connectivity, they are considered to be physical containers, with one site per location that is connected to AD by slower links. There are two major benefits to defining sites:

  • Client computers within a site are preferentially directed to local (within the same site) resources.

  • AD replication within the site happens without much regard for bandwidth consumption (because all segments are well connected at high bandwidth LAN speeds), but AD replication between sites, over slower wide area network (WAN) links, can be carefully controlled so as to avoid saturation of these lower bandwidth links. GPOs can be linked to sites.

AD Domains

AD domains are logical containers that are created within an AD forest. Domains (and AD) are created, and exist, on domain controllers. Domains in AD are security boundaries. In Windows Server 2003, they are defined by their unique namespace, like mobeer.com, buymeabeer.us, or boboville.com, as well as their single-password policy per domain. If you need a different namespace, you need another AD domain. If you need a different password policy for users, you need another AD domain. Domains are logical containers and can exist in multiple sites if placed in one or more domain controllers in more than one site. GPOs can be linked to the domain.

Note

Password Policies Password policies for domain users must be applied at the domain level.


Organizational Units (OUs)

Organizational Units (OUs) are logical containers that are created within an AD domain. They are designed to be used to organize computers and users for two purposes: to delegate administrative authority of groups of computers and users to different administrators, and to provide grouping of computers and users for the assignment of different Group Policy Objects (GPOs). OUs can be nested within another parent OU, so they create a hierarchical structure, like the one shown in Figure 1. GPOs can be linked to Organizational Units.

Figure 1. The hierarchical structure of OUs in an Active Directory domain.


The OU is represented in AD Tools by a folder with a book icon on it. A folder without a book icon on it is not an OU but is an AD container that cannot have GPOs linked to it. By default, AD provides only one OU called the Domain Controllers OU so that security-related GPOs can be applied to this most sensitive class of servers. Administrators must create all other OUs.

Policies are applied in the order of L-S-D-OU-OU-OU. That is the Local policy, then site policies, then domain policies, and finally OU policies, starting with the top-level OU, and then followed by its child OU, and then its child OU, and so on.

Policies have two halves:

  • A computer half, called the Computer Configuration

  • A user half, called the User Configuration (see Figure 2)

    Figure 2. Group Policy Objects can be applied to computers and users.
Other -----------------
- User Account Control (UAC)
- Troubleshoot Authentication Issues - SmartCards
- Configure and Troubleshoot Access to Resources (part 4) - Securing Network Traffic for Remote Desktop Protocol (RDP) Access
- Configure and Troubleshoot Access to Resources (part 3) - IPSec for Securing Network Traffic on the Local LAN
- Configure and Troubleshoot Access to Resources (part 2) - Printer Sharing
- Configure and Troubleshoot Access to Resources (part 1) - Permissions
- Windows Update (part 4) - Troubleshooting Updates
- Windows Update (part 3) - Windows Server Update Services Server (WSUS)
- Windows Update (part 2) - Automatic Updates
- Windows Update (part 1) - Manual Updates
- Windows Defender and Other Defenses Against Malware
- Windows Firewall
- Troubleshoot Security Configuration Issues (part 2) - Securing Data in Storage with Encrypting File System & Securing Computers with the Security Configuration and Analysis Tool
- Troubleshoot Security Configuration Issues (part 1) - The Windows Security Center & Securing the Operating System and Data in Storage with BitLocker
- Configure and Troubleshoot Security for Windows Internet Explorer 7 (part 4) - Digital Certificates
- Configure and Troubleshoot Security for Windows Internet Explorer 7 (part 3) - Cookie-Handling & ActiveX Opt-In
- Configure and Troubleshoot Security for Windows Internet Explorer 7 (part 2) - Internet Explorer’s Protected Mode
- Configure and Troubleshoot Security for Windows Internet Explorer 7 (part 1) - Pop-Up Blocker & Phishing Filter
- Troubleshooting Deployment Issues
- Perform Post-Installation Tasks (part 3) - Managing Computers with Multiple Operating Systems
 
 
Most view of day
- Windows Server 2012 : Installing roles and features (part 1) - Installing roles and features using Server Manager
- Multi-Tenancy in SharePoint 2013 (part 1) - Managing Service Application Groups, Creating a Site Subscription
- Microsoft Visio 2010 : Modifying a Graphic (part 3) - Changing a Graphic’s Position
- Microsoft Word 2010 : Working with Outlines - Creating a Multilevel List
- Windows Phone 8 : Configuring Basic Device Settings - Battery Saver
- Windows Phone 8 : Working with the Windows Phone Software (part 7) - Removing Multimedia Content - Removing a Video from Your Phone
- Microsoft Exchange Server 2007 : Upgrading Separate AD Forests to a Single Forest Using Mixed-Mode Domain Redirect (part 2)
- Microsoft Visio 2010 : Organizing and Annotating Diagrams - Markup & Review
- Microsoft Excel 2010 : Protecting and Securing a Workbook - Setting Macro Security Options
- Monitoring Windows Small Business Server 2011 : Using Performance Monitor
Top 10
- Sharepoint 2013 : Working with the CSOM (part 6) - Working with the JavaScript client object model - Creating, reading, updating, and deleting in the JavaScript client object model
- Sharepoint 2013 : Working with the CSOM (part 5) - Working with the JavaScript client object model - Handling errors
- Sharepoint 2013 : Working with the CSOM (part 4) - Working with the JavaScript client object model - Returning collections
- Sharepoint 2013 : Working with the CSOM (part 3) - Working with the managed client object model - Creating, reading, updating, and deleting
- Sharepoint 2013 : Working with the CSOM (part 2) - Working with the managed client object model - Handling errors
- Sharepoint 2013 : Working with the CSOM (part 1) - Understanding client object model fundamentals
- Windows Phone 8 : Configuring Mailbox Settings (part 5) - Configuring Automatic Replies
- Windows Phone 8 : Configuring Mailbox Settings (part 4) - Lightening the Display,Changing the Mailbox Sync Settings
- Windows Phone 8 : Configuring Mailbox Settings (part 3) - Message Signatures, Blind CCing Yourself
- Windows Phone 8 : Configuring Mailbox Settings (part 2) - Unlinking Mailboxes, Conversation View
 
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro