Imagine a world where every facet of your desktop environment is controlled, locked down, or otherwise centrally managed. In such a world, your corporate policies and indeed your every whim are explicitly defined for your users. You, the administrator, wield complete power in ensuring the safety, security, and functionality of your computing environment.
Such a situation would be an IT administrator's nirvana: Tired of poorly-written screen savers that consume resources and crash machines? Lock them out! Long for drive mappings that follow users wherever they go without the inconsistencies of login scripts? Enforce them! Yearn for a way to control the settings of applications (even third-party and custom applications!) to protect your users and ease your job? Cram them down, policy-style! With such complete power, you the all-powerful administrator could prevent problems from ever happening, ensure the highest reliability for your computing infrastructure, and in the end score that huge raise at your next annual review.
Does this sound like imagination? It's not. Such complete control over your desktop environment is achievable today. Best of all, its achievable using technologies you already have in place. What is this all-powerful technology? It's the same Group Policy that's been available since February 17th of the year 2000, now augmented with extra capabilities in Windows Server 2008. If you haven't played with Microsoft's not-entirely-new Group Policy Preferences, read on.
Policies and Preferences, Both Are Necessary
Back with the release of Windows 2000, Microsoft implemented a centralized solution for controlling settings across desktops and servers in an infrastructure. An almost entirely client-based solution, Group Policy began its lifespan as a mechanism for controlling Windows settings from a central configuration.
It is the "Policy" in Group Policy that is fundamentally important towards how this solution works. Think first about what a policy really is. Within a business, a policy is considered, "A written statement that communicates management's intent, objectives, requirements, responsibilities, and/or standards" (Source: www.cica.ca/index.cfm/ci_id/36552/page/1.htm). Policies define the position of a business' management and are usually considered inviolate. Once a business defines a policy, its employees are expected to follow the policy if they are to remain employees.
The same holds true with Group Policies. Once a Group Policy is applied, administrators should expect that that policy will remain in place until removed. Thus, a configured Group Policy will always be enforced. Should a user make a change that conflicts with the established policy, it will eventually be reset to its correct configuration during the next Group Policy refresh interval (which is typically 90 minutes plus a random offset).
Group Policies then are excellent tools for enforcing configurations that must be inviolate in your desktop environment. These settings, such as firewall configurations, security and auditing parameters, and some desktop control settings, make sense as being policy-driven.
But alongside these inviolate settings is another grouping of configurations that perhaps don't make sense as traditional "policies": Call them "suggestions" or "recommendations" or "preferences." Perhaps you want to suggest a certain desktop background, but you're OK if users make changes later. Maybe you want to configure an application or Windows settings in a certain way but not necessarily enforce that configuration after its initial setting.
It is for these situations that Group Policy Preferences (GPPs) are now available with Windows Server 2008. GPPs are an entirely different construct than traditional Group Policies, with the important exception in that they are applied in the same ways as Group Policies. Enabling a new GPP follows the same processes done with traditional Group Policies: Create the GPP, then apply the GPP to an Organizational Unit (OU) of objects. GPP settings that relate to users will be applied to users in that OU. GPP settings that relate to computers will be applied to computers in that OU.
More than Just Preferred
Many IT administrators find themselves confused about the "Preferences" part of GPPs. Being one of the three words that comprise a GPP's namesake, these admins incorrectly believe that GPP's "Preferences" component is really its most important. In reality, GPPs usefulness for the desktop environment goes far beyond just their capacity to be optional. GPPs, in addition to being preference-capable, are also comprised of a large swath of configuration capabilities that go far beyond what you could accomplish with traditional Group Policies.
Figure 1 shows a screenshot of the Group Policy Management Editor (GPME) on Windows Server 2008 R2. Expanded here are the preference categories available for the Computer Configuration half of a sample Group Policy Object (GPO). Here, you can see that a sample GPP can centrally manage and control elements previously unavailable with traditional Group Policies. Environment variables, files, folders, registry settings, local users and groups, printers, services-all of these elements in Figure 1 can be custom controlled through a GPP.
Figure 1: A list of GPP categories under Computer Configuration.
This list should immediately bring to mind some of the settings that you today may be configuring through login scripts. In fact, you can argue that the complete elimination of login scripts is one of the goals of GPPs. Eliminating logon scripts also eliminates the potential error that can propagate from an incorrectly-coded script. It removes your need to learn scripting languages to set preferences correctly. And, most importantly, it enables you to apply configurations in a much more consistent manner than with login scripts: No longer must you wait for users to logout and log back in to apply the script.
Further, as stated before, GPPs apply to computers in your domain in the same way as traditional Group Policies. Thus, your existing OU structure can be leveraged for GPP application in the same way that you're applying Group Policies today.
GPPs = Custom Control
Yet another design difference between traditional Group Policies and GPPs has to do with the options that are available for configuration. With some exceptions (as defined by Client Side Extensions-CSE) traditional Group Policies tend to be very on/off oriented. With traditional Group Policies, many of the selections available allow you to turn on or turn off some capability in the Windows environment.
GPPs by nature are much different. GPP settings do not have the same Enabled/Disabled/Not Configured toggle switches as with traditional Group Policy settings. With GPPs, creating a new setting effectively creates a container within which a specific change is stored. For example, in Figure 2, a new Environment setting has been created and opened for editing. Here, you can see how the Environment GPP setting provides a place to store the actual value of the Environment variable-much like you would do in a login script.
Figure 2: Using an Environment GPP to set an environment variable.
Each of the GPPs available natively with Windows Server 2008 behaves in about the same way. Let's review just a few:
- Folders provide a place to create or delete folders.
- Registry enables the creation, modification, or deletion of registry keys and values.
- Network Shares enables the creation and manipulation of network shares.
- Printers provide a place to connect network and local printers.
The list goes on. The combination of each of these categories provides a comprehensive location where virtually every facet of your desktop environment can be configured, controlled, and initially set up for your users. The result is a single location where you the administrator can establish a workspace baseline for all your desktops, setting policies where necessary, setting preferences where possible, and even enforcing certain preferences when you want absolute control.
Architecting Group Policy Preferences
Now that your appetite is whet with the potential power of GPPs, let's take a few minutes to discuss how they can be successfully implemented in your organization. First and foremost, the creation of any suite of GPP settings first requires a bit of background research. Before you ever begin creating GPPs to apply to your desktop, ask yourself a series of questions. The answers to these questions will assist you with creating the right structure of GPPs before you ever click through any wizards:
What settings do I currently control via login scripts? One major utility of GPPs is as a direct replacement for login scripts. If your organization uses login scripts (and who doesn't), GPPs provide an excellent solution for accomplishing their customization goals but with the reporting and event logging infrastructure of traditional Group Policy.
The first step in identifying which GPPs you should configure starts with a review of your login scripts. Are you mapping drives? Are you setting environment variables? Are you configuring network shares or printers for users? These and other settings can be immediately removed from login scripts and used as a starting point for your first GPPs.
What settings would I like to configure, but cannot with login scripts? Other desired settings are much more complicated to encode into login scripts, and as such are often relegated to manual configuration by field technicians. These can be ODBC connections for particular software packages, the configuration of local users and groups, or the creation of folder structures with the distribution of files.
Encoding any of these tasks into a script file that is useable by a login script is painful at best and impossible at worst. Look to your list of help desk tickets and common requests to find customizations that can be automated through their addition to a GPP.
What settings are commonly called into my help desk as problems? The metrics you may be generating through your help desk phone calls can be another excellent indicator of areas which require centralized control. Do you have applications that come equipped with the "never, never, never check this box" box? You know the check box: The very moment a user navigates through the application's Options menu and clicks the box, it breaks the application and forces a technician to visit their desk for a fix.
In these and other similar situations you can use a GPP setting to configure that box to never be checked, ensuring that the right configuration is always available for your users. Going a step further, by aligning your GPP configurations with those that cause the most pain for your help desk, you immediately gain a way to determine how successful their application can be. Apply GPPs and immediately reduce help desk calls; that's a success!
Which of these should be enforced and which should be optional? Each and every individual setting within a GPP can be set as optional or required. This is accomplished through each setting's Common tab as shown in Figure 3. There, look for the check box titled Apply once and do not reapply. By checking this box, the GPP will apply the setting once to any targeted computer, making the change on that computer. As long as the GPP setting exists it will not re-attempt to update a targeted desktop.
This check box is what brings the "Preferences" to Group Policy Preferences, and is independently set for each setting. This means that, for example, two separate environment variables can be configured, with one being a "preference" by checking the box and the other being a "policy" by not checking the box.
Figure 3: Only one setting in a GPP actually makes it a "Preference."
What is my OU configuration, and does it provide the granularity I need? As discussed earlier, GPPs are applied in the same ways as traditional Group Policies. This means that the structure of your domain's Organization Units will define how and where GPPs are applied. Today's best practices for OU structures relegate individual object types to their own OUs. This means that computer objects are typically stored in a different set of OUs than users. This separation of objects is done because both traditional Group Policies and GPPs have two halves-the "user" half and the "computer" half-with the computer half applying only to computers in the OU and the user half applying only to users (some exceptions apply, one very important example being when the User Group Policy loopback processing mode setting is configured). GPPs are no different. The user half of a GPP will apply to users in a targeted OU, with the computer half of a GPP applying to computers. GPPs do, however, have an extra power in their Item-level targeting, which will be discussed a bit later.
It is important to recognize that your domain's OU structure should be configured in a way that makes sense for Group Policy application. This can mean the distribution of users and computers into multiple OUs, or it can mean the aggregation of the same into smaller numbers of OUs. Your IT organization's needs will determine this architecture.
Is my OU structure too complicated? With the above question being answered, a second must also be asked. I present this question because in innumerable environments I've seen over years of consulting, I have found one common theme in many: An overly-complicated OU structure. Some structures were created with a desire to segregate users and computers by function, or by department, or by role. However, in these cases nothing was actually done with the objects once carefully segregated into their individual OUs.
Remember that OUs are for use by internal IT only, and in no place are exposed to the standard user. OUs are also not security principals in a Windows domain, which means that they cannot be used for applying security. Your OU structure should be defined by your need for Group Policy application in combination with any separation of duties requirements for user administration. Focusing on these two goals will ensure that you have the most flexible structure for use in configuration control.
With the answers to these questions, you can begin architecting the configurations you want to control using GPPs. Next, I'll show you how to accomplish that task.
No comments:
Post a Comment