Configure and Manage Group Policy - MCSA Windows Server 2012 R2 Administration Study Guide Exam 70-411 (2015)

MCSA Windows Server 2012 R2 Administration Study Guide Exam 70-411 (2015)

Chapter 7
Configure and Manage Group Policy

THE FOLLOWING 70-411 EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER:

1. image Configure Group Policy processing

§ Configure processing order and precedence

§ Configure blocking of inheritance

§ Configure enforced policies

§ Configure security filtering and wmi filtering

§ Configure loopback processing

§ Configure and manage slow-link processing and group policy caching

§ Configure client-side extension (CSE) behavior

§ Force group policy update

2. image Configure Group Policy settings

§ Configure settings including software installation, folder redirection, scripts, and administrative template settings

§ Import security templates

§ Import custom administrative template file

§ Convert administrative templates using admx migrator

§ Configure property filters for administrative templates

3. image Manage Group Policy objects (GPOs)

§ Back up, import, copy, and restore GPOs

§ Create and configure Migration Table

§ Reset default GPOs

§ Delegate Group Policy management

4. image Configure Group Policy Preferences (GPP)

§ Configure GPP settings including printers, network drive mappings, power options, custom registry settings, Control Panel settings, Internet Explorer settings, file and folder deployment, and shortcut deployment

§ Configure item-level targeting

One of the most important system administration features in Windows Server 2012 R2 and Active Directory is administering Group Policy objects (GPOs). By using GPOs, administrators can quickly and easily define restrictions on common actions and then apply them at the site, domain, or organizational unit (OU) level. In this chapter, you will see how group policies work, and then you will look at how to implement them within an Active Directory environment.

This chapter will show Windows Server 2012 R2 administrators how to build, link, and deploy GPOs. GPOs are a great way to set policies throughout your entire forest. GPOs are one of the tools that many administrators never use, but once you start using them, you won’t be able to stop. Not only can GPOs help you set policies for your users and computers, you can also install software and updates using GPOs.

If you have already taken and passed exam 70-410, then this chapter will be a good refresher with some added material and tips; this material will be on the 70-411 exam, so it will be best to take the extra time and go through the content again.

Introducing Group Policy Objects

Just like everything else, there are always pros and cons to whatever you are working on. Microsoft Windows-based operating systems have an advantage because of their flexibility and manageability. Administrators have the ability to lock down the Microsoft operating systems by placing some rules or policies onto the domain.

Administrators can configure many different options to suit the network environment and help follow corporate policies. However, having the flexibility to configure the network and the Windows operating system comes at a price—generally, end users on a network have the ability to configure many options that they should not be changing. For example, TCP/IP configuration and security policies should remain consistent for all client computers. In fact, end users really don’t need to be able to change these types of settings in the first place because many end users do not understand the purpose of these settings.

Windows Server 2012 R2 group policies are designed to provide system administrators with the ability to customize end-user settings and to place restrictions on the types of actions those users can perform. Group policies can be easily created by system administrators and then later applied to one or more users or computers within the environment. Although they ultimately do affect registry settings, it is much easier to configure and apply settings through the use of Group Policy than it is to make changes to the registry manually. To make management easy, Microsoft has given administrators the ability to change all Group Policy settings from within one Microsoft Management Console (MMC) snap-in called the Group Policy Management Console (GPMC).

Group policies have several potential uses. I’ll cover the use of group policies for software deployment, and I’ll also focus on the technical background of group policies and how they apply to general configuration management.

Let’s begin by looking at how group policies function.

Understanding Group Policy Settings

Group Policy settings are based on Group Policy administrative templates. These templates provide a list of user-friendly configuration options and specify the system settings to which they apply. For example, an option for a user or computer that reads Require A Specific Desktop Wallpaper Setting would map to a key in the registry that maintains this value. When the option is set, the appropriate change is made in the registry of the affected users and computers.

By default, Windows Server 2012 R2 comes with several administrative template files that you can use to manage common settings. Additionally, system administrators and applications developers can create their own administrative template files to set options for specific functionality.

Most Group Policy items have three different settings options:

Enabled Specifies that a setting for this GPO has been configured. Some settings require values or options to be set.

Disabled Specifies that this option is disabled for client computers. Note that disabling an option is a setting. That is, it specifies that the system administrator wants to disallow certain functionality.

Not Configured Specifies that these settings have been neither enabled nor disabled. Not Configured is the default option for most settings. It simply states that this group policy will not specify an option and that other policy settings may take precedence.

The specific options available (and their effects) will depend on the setting. Often, you will need additional information. For example, when setting the Account Lockout policy, you must specify how many bad login attempts may be made before the account is locked out. With this in mind, let’s look at the types of user and computer settings that can be managed.

Group Policy settings can apply to two types of Active Directory objects: User objects and Computer objects. Because both users and computers can be placed into groups and organized within OUs, this type of configuration simplifies the management of hundreds, or even thousands, of computers.

The main options you can configure within user and computer group policies are as follows:

Software Settings Software Settings options apply to specific applications and software that might be installed on the computer. System administrators can use these settings to make new applications available to end users and to control the default configuration for these applications.

Windows Settings Windows Settings options allow system administrators to customize the behavior of the Windows operating system. The specific options that are available here are divided into two types: user and computer. User-specific settings let you configure Internet Explorer (including the default home page and other settings). Computer settings include security options, such as Account Policy and Event Log options.

Administrative Templates Administrative Templates options are used to configure user and computer settings further. In addition to the default options available, system administrators can create their own administrative templates with custom options.

Group Policy Preferences The Windows Server 2012 R2 operating system includes Group Policy Preferences (GPPs) options, which give you more than 20 new Group Policy extensions. These extensions, in turn, give you a vast range of configurable settings within a Group Policy object. Included in the new Group Policy preference extensions are settings for folder options, mapped drives, printers, the registry, local users and groups, scheduled tasks, services, and the Start menu.

Besides providing easier management, Group Policy preferences give an administrator the ability to deploy settings for client computers without restricting the users from changing the settings. This gives an administrator the flexibility needed to decide which settings to enforce and which not to enforce.

Figure 7.1 shows some of the options that you can configure with Group Policy.

image

FIGURE 7.1 Group Policy configuration options

ADMX Central Store Another consideration in GPO settings is whether to set up an ADMX Central Store. GPO administrative template files are saved as ADMX (.admx) files and AMXL (.amxl) for the supported languages. To get the most benefit out of using administrative templates, you should create an ADMX Central Store.

You create the Central Store in the SYSVOL folder on a domain controller. The Central Store is a repository for all of your administrative templates, and the Group Policy tools checks it. The Group Policy tools then use any ADMX files that they find in the Central Store. These files then replicate to all domain controllers in the domain.

If you want your clients to be able to edit domain-based GPOs by using the ADMX files that are stored in the ADMX Central Store, you must be using Windows Vista, Windows 7, Windows 8, Server 2008, Server 2008 R2, Server 2012, or Server 2012 R2.

Security Template Security templates are used to configure security settings through a GPO. Some of the security settings that can be configured are settings for account policies, local policies, event logs, restricted groups, system services, and the registry.

Starter GPOs Starter Group Policy objects give administrators the ability to store a collection of Administrative Template policy settings in a single object. Administrators then have the ability to import and export Starter GPOs to distribute the GPOs easily to other environments. When a GPO is created from a Starter GPO, as with any template, the new GPO receives the settings and values that were defined from the Administrative Template policy in the Starter GPO.

The Security Settings Section of the GPO

One of the most important sections of a GPO is the Security Settings section. The Security Settings section, under the Windows Settings section, allows an administrator to secure many aspects of the computer and user policies. The following are some of the configurable options for the Security Settings section:

Computer Section Only of the GPO

§ Account Policies

§ Local Policies

§ Event Policies

§ Restricted Groups

§ System Services

§ Registry

§ File System

§ Wired Network

§ Windows Firewall with Advanced Security

§ Network List Manager Policies

§ Wireless Networks

§ Network Access Protection

§ Application Control Policies

§ IP Security Policies

§ Advanced Audit Policy Configuration

Computer and User Sections of the GPO

§ Public Key Policies

§ Software Restriction Policy

Restricted Groups Restricted Groups allows you to control group membership by using a GPO. The group membership to which I am referring is the normal Active Directory groups (domain local, global, and universal). Restricted Groups offers two configurable properties: Members and Members Of.

The users on the Members list do not belong to the restricted group. The users on the Members Of list do belong to the restricted group. When you configure a Restricted Group policy, members of the restricted group that are not on the Members list are removed. Users who are on the Members list who are not currently a member of the restricted group are added.

Software Restriction Policy Software restriction policies allow administrators to identify software and to control its ability to run on the user’s local computer, organizational unit, domain, or site. This prevents users from installing unauthorized software. Software Restriction Policy is discussed in greater detail in this chapter in the “Implementing Software Deployment” section.

Group Policy Objects

So far, I have discussed what group policies are designed to do. Now it’s time to drill down to determine exactly how you can set up and configure them.

To make them easier to manage, group policies may be placed in items called Group Policy Objects (GPOs). GPOs act as containers for the settings made within Group Policy files, which simplifies the management of settings. For example, as a system administrator, you might have different policies for users and computers in different departments. Based on these requirements, you could create a GPO for members of the Sales department and another for members of the Engineering department. Then you could apply the GPOs to the OU for each department. Another important concept you need to understand is that Group Policy settings are hierarchical; that is, system administrators can apply Group Policy settings at four different levels. These levels determine the GPO processing priority:

Local Every Windows operating system computer has one Group Policy object that is stored locally. This GPO functions for both the computer and user Group Policy processing.

Sites At the highest level, system administrators can configure GPOs to apply to entire sites within an Active Directory environment. These settings apply to all of the domains and servers that are part of a site. Group Policy settings managed at the site level may apply to more than one domain within the same forest. Therefore, they are useful when you want to make settings that apply to all of the domains within an Active Directory tree or forest.

Domains Domains are the third level to which system administrators can assign GPOs. GPO settings placed at the domain level will apply to all of the User and Computer objects within the domain. Usually, system administrators make master settings at the domain level.

Organizational Units The most granular level of settings for GPOs is the OU level. By configuring Group Policy options for OUs, system administrators can take advantage of the hierarchical structure of Active Directory. If the OU structure is planned well, you will find it easy to make logical GPO assignments for various business units at the OU level.

Based on the business needs and the organization of the Active Directory environment, system administrators might decide to set up Group Policy settings at any of these four levels. Because the settings are cumulative by default, a User object might receive policy settings from the site level, from the domain level, and from the OUs in which it is contained.

image You can also apply Group Policy settings to the local computer (in which case Active Directory is not used at all), but this limits the manageability of the Group Policy settings.

Group Policy Inheritance

In most cases, Group Policy settings are cumulative. For example, a GPO at the domain level might specify that all users within the domain must change their password every 60 days, and a GPO at the OU level might specify the default desktop background for all users and computers within that OU. In this case, both settings apply, and users within the OU are forced to change their password every 60 days and have the default desktop setting.

So, what happens if there’s a conflict in the settings? For example, suppose you create a scenario where a GPO at the site level specifies that users are to use red wallpaper and another GPO at the OU level specifies that they must use green wallpaper. The users at the OU layer would have green wallpaper by default. Although hypothetical, this raises an important point about inheritance. By default, the settings at the most specific level (in this case, the OU that contains the User object) override those at more general levels. As a friend of mine from Microsoft always says, “Last one to apply wins.”

Although the default behavior is for settings to be cumulative and inherited, system administrators can modify this behavior. They can set two main options at the various levels to which GPOs might apply:

Block Policy Inheritance The Block Policy Inheritance option specifies that Group Policy settings for an object are not inherited from its parents. You might use this, for example, when a child OU requires completely different settings from a parent OU. Note, however, that you should manage blocking policy inheritance carefully because this option allows other system administrators to override the settings made at higher levels.

Force Policy Inheritance The Enforced option (sometimes referred as the No Override) can be placed on a parent object and ensures that all lower-level objects inherit these settings. In some cases, system administrators want to ensure that Group Policy inheritance is not blocked at other levels. For example, suppose it is corporate policy that all network accounts are locked out after five incorrect password attempts. In this case, you would not want lower-level system administrators to override the option with other settings.

System administrators generally use this option when they want to enforce a specific setting globally. For example, if a password expiration policy should apply to all users and computers within a domain, a GPO with the Force Policy Inheritance option enabled could be created at the domain level.

You must consider one final case: If a conflict exists between the computer and user settings, the user settings take effect. If, for instance, a system administrator applies a default Desktop setting for the Computer policy and a different default Desktop setting for the User policy, the one they specify in the User policy takes effect. This is because the user settings are more specific, and they allow system administrators to make changes for individual users regardless of the computer that they’re using.

Planning a Group Policy Strategy

Through the use of Group Policy settings, system administrators can control many different aspects of their network environment. As you’ll see throughout this chapter, system administrators can use GPOs to configure user settings and computer configurations. Windows Server 2012 R2 includes many different administrative tools for performing these tasks. However, it’s important to keep in mind that, as with many aspects of using Active Directory, a successful Group Policy strategy involves planning.

Because there are hundreds of possible Group Policy settings and many different ways to implement them, you should start by determining the business and technical needs of your organization. For example, you should first group your users based on their work functions. You might find, for example, that users in remote branch offices require particular network configuration options. In that case, you might implement Group Policy settings best at the site level. In another instance, you might find that certain departments have varying requirements for disk quota settings. In this case, it would probably make the most sense to apply GPOs to the appropriate department OUs within the domain.

The overall goal should be to reduce complexity (for example, by reducing the overall number of GPOs and GPO links) while still meeting the needs of your users. By taking into account the various needs of your users and the parts of your organization, you can often determine a logical and efficient method of creating and applying GPOs. Although it’s rare that you’ll come across a right or wrong method of implementing Group Policy settings, you will usually encounter some that are either better or worse than others.

By implementing a logical and consistent set of policies, you’ll also be well prepared to troubleshoot any problems that might come up or to adapt to your organization’s changing requirements. Later in this chapter, you’ll learn about some specific methods for determining effective Group Policy settings before you apply them.

Implementing Group Policy

Now that I’ve covered the basic layout and structure of group policies and how they work, let’s look at how you can implement them in an Active Directory environment. In the following sections, you’ll start by creating GPOs. Then you’ll apply these GPOs to specific Active Directory objects, and you’ll take a look at how to use administrative templates.

Creating GPOs

In Windows Server 2000 and 2003, you could create GPOs from many different locations. For example, in Windows Server 2003, you could use Active Directory Users and Computers to create GPOs on your OUs along with other GPO tools. In Windows Server 2012 R2, things are simpler. You can create GPOs for OUs in only one location: the Group Policy Management Console (GPMC). You have your choice of three applications for setting up policies on your Windows Server 2012 R2 computers:

Local Computer Policy Tool This administrative tool allows you to access quickly the Group Policy settings that are available for the local computer. These options apply to the local machine and to users who access it. You must be a member of the local administrators group to access and make changes to these settings.

Group Policy Management Console You must use the GPMC to manage Group Policy deployment. The GPMC provides a single solution for managing all Group Policy–related tasks, and it is also best suited to handle enterprise-level tasks, such as forest-related work.

The GPMC allows administrators to manage Group Policy and GPOs all from one easy-to-use console whether their enterprise solution spans multiple domains and sites within one or more forests or it is local to one site. The GPMC adds flexibility, manageability, and functionality. Using this console, you can also perform other functions, such as backup and restore, importing, and copying.

Auditpol.exe Auditpol.exe is a command-line utility that works with Windows Vista, Windows 7, Windows 8, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. An administrator has the ability to display information about policies and also to perform some functions to manipulate audit policies. Table 7.1 shows some of the switches available for auditpol.exe.

TABLE 7.1 Auditpol.exe switches

Switch

Explanation

/?

This is the auditpol.exe help command.

/get

Allows you to display the current audit policy.

/set

Allows you to set a policy.

/list

Displays selectable policy elements.

/backup

Allows you to save the audit policy to a file.

/restore

Restores a policy from previous backup.

/clear

Clears the audit policy.

/remove

Removes all per-user audit policy settings and disables all system audit policy settings.

/ResourceSACL

Configures the Global Resource SACL.

Exercise 7.1 walks you through the process of installing the Group Policy Management MMC snap-in for editing Group Policy settings and creating a GPO.

image You should be careful when making Group Policy settings because certain options might prevent the proper use of systems on your network. Always test Group Policy settings on a small group of users before you deploy them throughout your organization. You’ll probably find that some settings need to be changed to be effective.

image EXERCISE 7.1: Creating a Group Policy Object Using the GPMC

1. Press the Windows button and choose Administrative Tools ⇒ Group Policy Management. The Group Policy Management tool opens.

2. Expand the Forest, Domains, your domain name, and North America containers. Right-click the Corporate OU and then choose Create A GPO In This Domain, And Link It Here.

3. When the New GPO dialog box appears, type Logon Message in the Name field. Click OK.

4. The New GPO will be listed on the right side of the Group Policy Management window. Right-click the GPO and choose Edit.image

5. In the Group Policy Management Editor, expand the following: Computer Configuration ⇒ Policies ⇒ Windows Settings ⇒ Security Settings ⇒ Local Policies ⇒ Security Options. On the right side, scroll down and double-click Interactive Logon: Message Text For Users Attempting To Log On.

6. Click the box labeled Define This Policy Setting In The Template. In the text box, type Welcome to the domain. Domain members only are welcome and then click OK. Close the GPO and return to the GPMC main screen.image

7. Under the domain name (in the GPMC), right-click Group Policy Objects and choose New.

8. When the New GPO dialog box appears, type Unlinked Test GPO in the Name field. Click OK.

9. On the right side, the new GPO will appear. Right-click Unlinked Test GPO and choose Edit.

10.In the User Configuration section, click Policies ⇒ Administrative Templates ⇒ Desktop. On the right side, double-click Hide And Disable All Items On The Desktop and then click Enabled. Click OK and then close the GPMC.image

image Note that Group Policy changes may not take effect until the next user logs in (some settings may even require that the machine be rebooted). That is, users who are currently working on the system will not see the effects of the changes until they log off and log in again. GPOs are reapplied every 90 minutes with a 30-minute offset. In other words, users who are logged in will have their policies reapplied every 60 to 120 minutes. Not all settings are reapplied (for example, software settings and password policies).

Linking Existing GPOs to Active Directory

Creating a GPO is the first step in assigning group policies. The second step is to link the GPO to a specific Active Directory object. As mentioned earlier in this chapter, GPOs can be linked to sites, domains, and OUs.

Exercise 7.2 walks you through the steps you must take to assign an existing GPO to an OU within the local domain. In this exercise, you will link the Test Domain Policy GPO to an OU. To complete the steps in this exercise, you must have completed Exercise 7.1.

EXERCISE 7.2: Linking Existing GPOs to Active Directory

1. Open the Group Policy Management Console.

2. Expand the Forest and Domain containers and right-click the Africa OU.

3. Choose Link An Existing GPO.

4. The Select GPO dialog box appears. Click Unlinked Test GPO and click OK.

5. Close the Group Policy Management Console.

Note that the GPMC tool offers a lot of flexibility in assigning GPOs. You can create new GPOs, add multiple GPOs, edit them directly, change priority settings, remove links, and delete GPOs all from within this interface. In general, creating new GPOs using the GPMC tool is the quickest and easiest way to create the settings you need.

To test the Group Policy settings, you can simply create a user account within the Africa OU that you used in Exercise 7.2. Then, using another computer that is a member of the same domain, you can log on as the newly created user.

Forcing a GPO to Update

There will be times when you need a GPO to get processed immediately. If you are testing a GPO, you will not want to wait for the GPO to process in its own time or you may not want to have to log off the domain and log back onto the domain just to get the GPO processed.

Windows Server 2012 R2 has changed how GPOs get processed. In a Windows Server 2012 R2 domain, when a user logs onto the domain, the latest version of the Group Policy gets downloaded from the domain controller, and it writes that policy to the local store.

If you have your GPOs set up and running in synchronous mode, then the next time the computer restarts, it will use the most recently downloaded GPO from the local store and not download the GPO from the domain. This is a new feature in Windows Server 2012 R2, and it helps to reduce the time it takes to log onto the domain because the GPO policy doesn’t need to be downloaded each time.

So, now that you understand how GPOs get processed in Windows Server 2012 R2, let’s look at a few different ways that you can force a GPO to get processed immediately.

Forcing the GPO from the Server

Windows Server 2012 R2 has an MMC called Group Policy Management Console (GPMC), and by using this MMC, you can remotely refresh an organizational unit (OU) and force the GPO on all users and computers within that OU. The GPMC remote refresh automatically updates all settings, including security settings, which are configured in the GPO that is linked to the OU. In the OU’s context menu, you can choose to refresh remotely the OU and the GPOs associated with that OU. When you remotely refresh an OU, the following steps occur:

1. Windows Server 2012 R2 does an Active Directory query, and that query returns a list of all users and computers that belong to the OU.

2. Windows Management Instrumentation (WMI) queries all users and computers that are currently logged into the domain and creates a list that will be used.

3. Using the list that was created in step 2, a remote scheduled task is created, and a GPUpdate.exe /force is executed on all of the users and computers that are logged into the domain. The remote scheduled task is then scheduled to execute with a 10-minute random delay to help decrease the load on network traffic.

image When you are using the GPMC to force a GPO update, you do not have the ability to change the 10-minute random delay, but if you force the GPO through the use of PowerShell, you have the ability to set the delay.

Another way that you can force a GPO to update immediately is to use Windows PowerShell. By using the PowerShell command Invoke-GPUpdate cmdlet, you cannot only force the GPO but also set the parameters to be more granular.

Forcing the GPO from the Client

As an administrator, you have the ability also to force a GPO onto a client machine on which you may be working. The GPUpdate.exe command allows you to run a GPO on a client machine. The GPUpdate command will run on all Windows client machines from Windows Vista to Windows Server 2012 R2. Table 7.2 shows some of the GPUpdate switches you can use.

TABLE 7.2 GPUpdate.exe switches

Switch

Description

/target:{Computer | User}

Updates only the User or Computer policy settings for the computer or user specified.

/force

Forces the GPO to reapply all policy settings. By default, only policy settings that have changed are applied.

/wait:<VALUE>

Determines the number of seconds that the system will wait after a policy is processed before returning to the command prompt.

/logoff

The domain user account will automatically log off the computer after the Group Policy settings are updated.

/boot

The computer will automatically restart after the Group Policy settings are applied.

/sync

This switch forces the next available foreground policy application to be done synchronously. Foreground policies are applied when the computer boots up and the user logs in.

/?

Displays help at the command prompt.

Managing Group Policy

Now that you have implemented GPOs and applied them to sites, domains, and OUs within Active Directory, it’s time to look at some ways to manage them. In the following sections, you’ll look at how multiple GPOs can interact with one another and ways that you can provide security for GPO management. Using these features is an important part of working with Active Directory, and if you properly plan Group Policy, you can greatly reduce the time the help desk spends troubleshooting common problems.

Managing GPOs

One of the benefits of GPOs is that they’re modular and can apply to many different objects and levels within Active Directory. This can also be one of the drawbacks of GPOs if they’re not managed properly. A common administrative function related to using GPOs is finding all of the Active Directory links for each of these objects. You can do this when you are viewing the Linked Group Policy Objects tab of the site, domain, or OU in the GPMC (shown in Figure 7.2).

image

FIGURE 7.2 Viewing GPO links to an Active Directory OU

In addition to the common action of delegating permissions on OUs, you can set permissions regarding the modification of GPOs. The best way to accomplish this is to add users to the Group Policy Creator/Owners built-in security group. The members of this group are able to modify security policy.

Windows Management Instrumentation

Windows Management Instrumentation (WMI) scripts are used to gather information or to help GPOs deploy better. The best way to explain this is to give an example. Let’s say you wanted to deploy Microsoft Office 2013 to everyone in the company. You would first set up a GPO to deploy the Office package (explained later in the section “Deploying Software Through a GPO”).

You can then place a WMI script on the GPO stating that only computers with 10GB of hard disk space actually deploy Office. Now if a computer has 10GB of free space, the Office GPO would get installed. If the computer does not have the 10GB of hard disk space, the GPO will not deploy. You can use WMI scripts to check for computer information such as MAC addresses. WMI is a powerful tool because if you know how to write scripts, the possibilities are endless. The following script is a sample of a WMI that is checking for at least 10GB of free space on the C: partition/volume:

Select ∗ from Win32_LogicalDisk where FreeSpace > 10737418240 AND Caption = "C:"

Security Filtering of a Group Policy

Another method of securing access to GPOs is to set permissions on the GPOs themselves. You can do this by opening the GPMC, selecting the GPO, and clicking the Advanced button in the Delegation tab. The Unlinked Test GPO Security Settings dialog box appears (see Figure 7.3).

image

FIGURE 7.3 A GPO’s Security Settings dialog box

The following permissions options are available:

§ Full Control

§ Read

§ Write

§ Create All Child Objects

§ Delete All Child Objects

§ Apply Group Policy

You might have to scroll the Permissions window to see the Apply Group Policy item. Of these, the Apply Group Policy setting is particularly important because you use it to filter the scope of the GPO. Filtering is the process by which selected security groups are included or excluded from the effects of the GPOs. To specify that the settings should apply to a GPO, you should select the Allow check box for both the Apply Group Policy setting and the Read setting. These settings will be applied only if the security group is also contained within a site, domain, or OU to which the GPO is linked. To disable GPO access for a group, choose Deny for both of these settings. Finally, if you do not want to specify either Allow or Deny, leave both boxes blank. This is effectively the same as having no setting.

In Exercise 7.3, you will filter Group Policy using security groups. To complete the steps in this exercise, you must have completed Exercises 7.1 and 7.2.

EXERCISE 7.3: Filtering Group Policy Using Security Groups

1. Open the Active Directory Users and Computers administrative tool.

2. Create a new OU called Group Policy Test.

3. Create two new global security groups within the Group Policy Test OU, and name them PolicyEnabled and PolicyDisabled.

4. Exit Active Directory Users and Computers and open the GPMC.

5. Right-click the Group Policy Test OU and select Link An Existing GPO.

6. Choose Unlinked Test GPO and click OK.

7. Expand the Group Policy Test OU so that you can see the GPO (Unlinked Test GPO) underneath the OU.

8. Click the Delegation tab and then click the Advanced button in the lower-right corner of the window.

9. Click the Add button and type PolicyEnabled in the Enter The Object Names To Select field. Click the Check Names button. Then click OK.

10.Add a group named PolicyDisabled in the same way.

11.Highlight the PolicyEnabled group and select Allow for the Read and Apply Group Policy permissions. This ensures that users in the PolicyEnabled group will be affected by this policy.

12.Highlight the PolicyDisabled group and select Deny for the Read and Apply Group Policy permissions. This ensures that users in the PolicyDisabled group will not be affected by this policy.

13.Click OK. You will see a message stating that you are choosing to use the Deny permission and that the Deny permission takes precedence over the Allow entries. Click the Yes button to continue.

14.When you have finished, close the GPMC tool.

Delegating Administrative Control of GPOs

So far, you have learned about how to use Group Policy to manage user and computer settings. What you haven’t done yet is to determine who can modify GPOs. It’s important to establish the appropriate security on GPOs themselves for two reasons:

§ If the security settings aren’t set properly, users and system administrators can easily override them. This defeats the purpose of having the GPOs in the first place.

§ Having many different system administrators creating and modifying GPOs can become extremely difficult to manage. When problems arise, the hierarchical nature of GPO inheritance can make it difficult to pinpoint the problem.

Fortunately, through the use of delegation, determining security permissions for GPOs is a simple task. Exercise 7.4 walks you through the steps you must take to grant the appropriate permissions to a user account. Specifically, the process involves delegating the ability to manage Group Policy links on an Active Directory object (such as an OU). To complete this exercise, you must have completed Exercises 7.1 and 7.2.

EXERCISE 7.4: Delegating Administrative Control of Group Policy

1. Open the Active Directory Users and Computers tool.

2. Expand the local domain, and create a user named Policy Admin within the Group Policy Test OU.

3. Exit Active Directory Users and Computers and open the GPMC.

4. Click the Group Policy Test OU and select the Delegation tab.

5. Click the Add button. In the field labeled Enter The Object Name To Select, type Policy Admin and click the Check Names button.

6. The Add Group Or User dialog box appears. In the Permissions drop-down list, make sure that the item labeled Edit Settings, Delete, Modify Security is chosen. Click OK.image

7. At this point, you should be looking at the Group Policy Test Delegation window. Click the Advanced button in the lower-right corner.

8. Highlight the Policy Admin account and check the Allow Full Control box. This user now has full control of these OUs and all child OUs and GPOs for these OUs. Click OK.

If you just want to give individual rights to this user, then in the Properties window (step 8), click the Advanced button and then the Effective Permissions tab. This is where you can also choose a user and give them only the rights that you want them to have.

9. When you have finished, close the GPMC tool.

Understanding Delegation

Although I have talked about delegation throughout the book, it’s important to discuss it again in the context of OUs, Group Policy, and Active Directory.

Once configured, Active Directory administrative delegation allows an administrator to delegate tasks (usually administration related) to specific user accounts or groups. What this means is that if you don’t manage it all, the user accounts (or groups) you choose will be able to manage their portions of the tree.

It’s important to be aware of the benefits of Active Directory Delegation (AD Delegation). AD Delegation will help you manage the assigning of administrative control over objects in Active Directory, such as users, groups, computers, printers, domains, and sites. AD Delegation is used to create more administrators, which essentially saves time.

For example, let’s say you have a company whose IT department is small and situated in a central location. The central location connects three other smaller remote sites. These sites do not each warrant a full-time IT person, but the manager on staff (for example) at each remote site can become an administrator for their portion of the tree. If the user accounts for the staff at the remote site are managed by that manager, this reduces the burden on the system administrator of trivial administrative work, such as unlocking user accounts or changing passwords, and thus it reduces costs.

Controlling Inheritance and Filtering Group Policy

Controlling inheritance is an important function when you are managing GPOs. Earlier in this chapter, you learned that, by default, GPO settings flow from higher-level Active Directory objects to lower-level ones. For example, the effective set of Group Policy settings for a user might be based on GPOs assigned at the site level, at the domain level, and in the OU hierarchy. In general, this is probably the behavior you would want.

In some cases, however, you might want to block Group Policy inheritance. You can accomplish this easily by selecting the object to which a GPO has been linked. Right-click the object and choose Block Inheritance (see Figure 7.4). By enabling this option, you areeffectively specifying that this object starts with a clean slate; that is, no other Group Policy settings will apply to the contents of this Active Directory site, domain, or OU.

image

FIGURE 7.4 Blocking GPO inheritance

System administrators can also force inheritance. By setting the Enforced option, they can prevent other system administrators from making changes to default policies. You can set the Enforced option by right-clicking the GPO and choosing the Enforced item (seeFigure 7.5).

image

FIGURE 7.5 Setting the Enforced GPO option

Assigning Script Policies

System administrators might want to make several changes and implement certain settings that would apply while the computer is starting up or the user is logging on. Perhaps the most common operation that logon scripts perform is mapping network drives. Although users can manually map network drives, providing this functionality within login scripts ensures that mappings stay consistent and that users only need to remember the drive letters for their resources.

Script policies are specific options that are part of Group Policy settings for users and computers. These settings direct the operating system to the specific files that should be processed during the startup/shutdown or logon/logoff processes. You can create the scripts by using the Windows Script Host (WSH) or with standard batch file commands. WSH allows developers and system administrators to create scripts quickly and easily using Visual Basic Scripting Edition (VBScript) or JScript (Microsoft’s implementation of JavaScript). Additionally, WSH can be expanded to accommodate other common scripting languages.

To set script policy options, you simply edit the Group Policy settings. As shown in Figure 7.6, there are two main areas for setting script policy settings.

image

FIGURE 7.6 Viewing Startup/Shutdown script policy settings

Startup/Shutdown Scripts These settings are located within the Computer Configuration ⇒ Windows Settings ⇒ Scripts (Startup/Shutdown) object.

Logon/Logoff Scripts These settings are located within the User Configuration ⇒ Windows Settings ⇒ Scripts (Logon/Logoff) object.

To assign scripts, simply double-click the setting and its Properties dialog box appears. For instance, if you double-click the Startup setting, the Startup Properties dialog box appears (see Figure 7.7). To add a script filename, click the Add button. When you do, you will be asked to provide the name of the script file (such as MapNetworkDrives.vbs or ResetEnvironment.bat).

image

FIGURE 7.7 Setting scripting options

Note that you can change the order in which the scripts are run by using the Up and Down buttons. The Show Files button opens the directory folder in which you should store the Logon script files. To ensure that the files are replicated to all domain controllers, you should be sure that you place the files within the SYSVOL share.

Understanding the Loopback Policy

There may be times when the user settings of a Group Policy object should be applied to a computer based on its location instead of the user object. Usually, the user Group Policy processing dictates that the GPOs be applied in order during computer startup based on the computers located in their organizational unit. User GPOs, on the other hand, are applied in order during logon, regardless of the computer to which they log on.

In some situations, this processing order may not be appropriate. A good example is a kiosk machine. You would not want applications that have been assigned or published to a user to be installed when the user is logged on to the kiosk machine. Loopback Policyallows two ways to retrieve the list of GPOs for any user when they are using a specific computer in an OU:

Merge Mode The GPOs for the computer are added to the end of the GPOs for the user. Because of this, the computer’s GPOs have higher precedence than the user’s GPOs.

Replace Mode In Replace mode, the user’s GPOs are not used. Only the GPOs of the Computer object are used.

Managing Network Configuration

Group policies are also useful in network configuration. Although administrators can handle network settings at the protocol level using many different methods, such as Dynamic Host Configuration Protocol (DHCP), Group Policy allows them to set which functions and operations are available to users and computers.

Figure 7.8 shows some of the features that are available for managing Group Policy settings. The paths to these settings are as follows:

image

FIGURE 7.8 Viewing Group Policy User network configuration options

Computer Network Options These settings are located within Computer Configuration ⇒ Administrative Templates ⇒ Network ⇒ Network Connections folder.

User Network Options These settings are located within User Configuration ⇒ Administrative Templates ⇒ Network.

Here are some examples of the types of settings available:

§ The ability to allow or disallow the modification of network settings.

In many environments, the improper changing of network configurations and protocol settings is a common cause of help desk calls.

§ The ability to allow or disallow the creation of Remote Access Service (RAS) connections.

This option is very useful, especially in larger networked environments, because the use of modems and other WAN devices can pose a security threat to the network.

§ The ability to set offline files and folders options.

This is especially useful for keeping files synchronized for traveling users, and it is commonly configured for laptops.

Each setting includes detailed instructions in the description area of the GPO Editor window. By using these configuration options, system administrators can maintain consistency for users and computers and avoid many of the most common troubleshooting calls.

Automatically Enrolling User and Computer Certificates in Group Policy

You can also use Group Policy to enroll user and computer certificates automatically, making the entire certificate process transparent to your end users. Before proceeding further, you should understand what certificates are and why they are an important part of network security.

Think of a digital certificate as a carrying case for a public key. A certificate contains the public key and a set of attributes, including the key holder’s name and email address. These attributes specify something about the holder: their identity, what they’re allowed to do with the certificate, and so on. The attributes and the public key are bound together because the certificate is digitally signed by the entity that issued it. Anyone who wants to verify the certificate’s contents can verify the issuer’s signature.

Certificates are one part of what security experts call a public-key infrastructure (PKI). A PKI has several components that you can mix and match to achieve the desired results. Microsoft’s PKI implementation offers the following functions:

Certificate Authorities CAs issue certificates, revoke certificates they’ve issued, and publish certificates for their clients. Big CAs like Thawte and VeriSign do this for millions of users. If you want, you can also set up your own CA for each department or workgroup in your organization. Each CA is responsible for choosing which attributes it will include in a certificate and what mechanism it will use to verify those attributes before it issues the certificate.

Certificate Publishers They make certificates publicly available, inside or outside an organization. This allows widespread availability of the critical material needed to support the entire PKI.

PKI-Savvy Applications These allow you and your users to do useful things with certificates, such as encrypt email or network connections. Ideally, the user shouldn’t have to know (or even be aware of) what the application is doing—everything should work seamlessly and automatically. The best-known examples of PKI-savvy applications are web browsers such as Internet Explorer and Firefox and email applications such as Outlook and Outlook Express.

Certificate Templates These act like rubber stamps. By specifying a particular template as the model you want to use for a newly issued certificate, you’re actually telling the CA which optional attributes to add to the certificate as well as implicitly telling it how to fill some of the mandatory attributes. Templates greatly simplify the process of issuing certificates because they keep you from having to memorize the names of all the attributes that you may potentially want to put in a certificate.

Learn More About PKI

When discussing certificates, it’s also important to mention PKI and its definition. The exam doesn’t go deeply into PKI, but I recommend you do some extra research on your own because it is an important technology and shouldn’t be overlooked. PKI is actually a simple concept with a lot of moving parts. When broken down to its bare essentials, PKI is nothing more than a server and workstations utilizing a software service to add security to your infrastructure. When you use PKI, you are adding a layer of protection. The auto-enrollment Settings policy determines whether users and/or computers are automatically enrolled for the appropriate certificates when necessary. By default, this policy is enabled if a certificate server is installed, but you can make changes to the settings, as shown in Exercise 7.5.

In Exercise 7.5, you will learn how to configure automatic certificate enrollment in Group Policy. You must have first completed the other exercises in this chapter in order to proceed with Exercise 7.5.

EXERCISE 7.5: Configuring Automatic Certificate Enrollment in Group Policy

1. Open the Group Policy Management Console tool.

2. Right-click the North America OU that you created in the previous exercises in this book.

3. Choose Create A GPO In This Domain And Link It Here and name it Test CA. Click OK.

4. Right-click the Test CA GPO and choose Edit.

5. Open Computer Configuration ⇒ Policies ⇒ Windows Settings ⇒ Security Settings ⇒ Public Key Policies.

6. Double-click Certificate Services Client – Auto-Enrollment in the right pane.image

7. The Certificate Services Client – Auto-Enrollment Properties dialog box will appear.

8. For now, don’t change anything. Just become familiar with the settings in this dialog box. Click OK to close it.

Redirecting Folders

Another set of Group Policy settings that you will learn about are the folder redirection settings. Group Policy provides a means for redirecting the Documents, Desktop, and Start Menu folders, as well as cached application data, to network locations. Folder redirection is particularly useful for the following reasons:

§ When they are using roaming user profiles, a user’s Documents folder is copied to the local machine each time they log on. This requires high-bandwidth consumption and time if the Documents folder is large. If you redirect the Documents folder, it stays in the redirected location, and the user opens and saves files directly to that location.

§ Documents are always available no matter where the user logs on.

§ Data in the shared location can be backed up during the normal backup cycle without user intervention.

§ Data can be redirected to a more robust server-side administered disk that is less prone to physical and user errors.

When you decide to redirect folders, you have two options, basic and advanced:

§ Basic redirection redirects everyone’s folders to the same location (but each user gets their own folder within that location).

§ Advanced redirection redirects folders to different locations based on group membership. For instance, you could configure the Engineers group to redirect their folders to //Engineering1/Documents/ and the Marketing group to //Marketing1/Documents/. Again, individual users still get their own folder within the redirected location.

To configure folder redirection, follow the steps in Exercise 7.6. You must have completed the other exercises in this chapter to proceed with this exercise.

image EXERCISE 7.6: Configuring Folder Redirection in Group Policy

1. Open the GPMC tool.

2. Open the North America OU and then edit the Test CA GPO.

3. Open User Configuration ⇒ Policies ⇒ Windows Settings ⇒ Folder Redirection ⇒ Documents.image

4. Right-click Documents and select Properties.

5. On the Target tab of the Documents Properties dialog box, choose the Basic – Redirect Everyone’s Folder To The Same Location selection from the Settings drop-down list.

6. Leave the default option for the Target Folder Location drop-down list and specify a network path in the Root Path field.

7. Click the Settings tab. All of the default settings are self-explanatory and should typically be left at the defaults. Click OK when you have finished.

Folder Redirection Facts

Try not to mix up the concepts of folder redirection and offline folders, especially in a world with ever-increasing numbers of mobile users. Folder redirection and offline folders are different features.

Windows Server 2012 R2 folder redirection works as follows: The system uses a pointer that moves the folders you want to a location that you specify. Users do not see any of this—it is transparent to them. One problem with folder redirection is that it does not work for mobile users (users who will be offline and who will not have access to files that they may need).

Offline folders, however, are copies of folders that were local to you. Files are now available locally to you on the system you have with you. They are also located back on the server where they are stored. The next time you log in, the folders are synchronized so that both folders contain the latest data. This is a perfect feature for mobile users, whereas folder redirection provides no benefit for the mobile user.

Managing GPOs with Windows PowerShell Group Policy Cmdlets

As stated earlier in this book, Windows PowerShell is a Windows command-line shell and scripting language. Windows PowerShell can also help an administrator automate many of the same tasks that you perform using the Group Policy Management Console.

Windows Server 2012 R2 helps you perform many of the Group Policy tasks by providing more than 25 cmdlets. Each of these cmdlets is a simple, single-function command-line tool.

The Windows PowerShell Group Policy cmdlets can help you perform some of the following tasks for domain-based Group Policy objects:

§ Maintain, create, remove, back up, and import GPOs.

§ Create, update, and remove GPO links to Active Directory containers.

§ Set Active Directory OUs and domain permissions and inheritance flags.

§ Configure Group Policy registry settings.

§ Create and edit Starter GPOs.

The requirement for Windows PowerShell Group Policy cmdlets is Windows Server 2012 R2 on either a domain controller or a member server that has the GPMC installed. Windows 7 and Windows 8 also have the ability to use Windows PowerShell Group Policy cmdlets if it has Remote Server Administration Tools (RSAT) installed. RSAT includes the GPMC and its cmdlets. PowerShell is also a requirement.

Item-Level Targeting

Administrators have the ability to apply individual preference items only to selected users or computers using a GPO feature called item-level targeting. Item-level targeting allows an administrator to select specific items that the GPO will look at and then apply that GPO only to the specific users or computers. Administrators have the ability to include multiple preference items, and each item can be customized for specific users or computers to use.

The target item has a value that belongs to it, and the value can be either true or false. Administrators can get even more granular by using the operation command of AND or OR while building this GPO, and this will allow an administrator to combine the targeted items with the preceding one. Once all of the conditions are executed, if the final value is false, then the GPO is not applied. If the final value is true, the GPO is applied to the users or computers that were previously determined. Administrators have the ability to item-target the following items:

§ Battery Present Targeting

§ Computer Name Targeting

§ CPU Speed Targeting

§ Date Match Targeting

§ Disk Space Targeting

§ Domain Targeting

§ Environment Variable Targeting

§ File Match Targeting

§ IP Address Range Targeting

§ Language Targeting

§ LDAP Query Targeting

§ MAC Address Range Targeting

§ MSI Query Targeting

§ Network Connection Targeting

§ Operating System Targeting

§ Organizational Unit Targeting

§ PCMCIA Present Targeting

§ Portable Computer Targeting

§ Processing Mode Targeting

§ RAM Targeting

§ Registry Match Targeting

§ Security Group Targeting

§ Site Targeting

§ Terminal Session Targeting

§ Time Range Targeting

§ User Targeting

§ WMI Query Targeting

Administrators can easily set up item-level targeting by following these steps:

1. Open the Group Policy Management Console. Select the GPO that will contain the new preferences by right-clicking the GPO and then choose Edit.

2. In the console tree under Computer Configuration or User Configuration, expand the Preferences folder and then browse to the preference extension.

3. Double-click the node for the preference extension and then right-click the preference item and click Properties.

4. In the Properties dialog box, click the Common tab.

5. Select Item-Level Targeting and then click Targeting.

6. Click New Item. If you are configuring multiple targeted items, on the Item Option menu, click the logical operation (AND or OR). Then click OK when finished.

7. Click the OK button on the Properties dialog box, and you are all set.

Backup, Restore, Import, Copy, and Migration Tables

One of the biggest advantages of using the Group Policy Management Console is that it is a one-stop shopping utility. You can do everything you need to do for GPOs in one location. The GPMC not only allows you to create and link a GPO but also lets you backup, restore, import, copy, and use migration tables.

Backing Up a GPO

Since this book is about Windows Server 2012 R2 and everything you should do to set up the server properly, then you most likely already understand what backups can do for you.

The reason we back up data as an administrator is in the event of a crash or major error that requires us to reload data to the server. Backups should be done daily on all data that is important to your organization. Backups can be done either by using Windows Server 2012 R2’s backup utility, or you can purchase third party software/hardware to back up your data.

I am an IT Director, and data recoverability is one of the most critical items that I deal with on a daily basis. I use a third-party hardware device from a company called Unitrends. This is just one of many companies that helps protect an organization’s data.

This hardware device does hourly backups for all of my servers. One of the nice features of the Unitrends box is that it backs up onto the hardware device and then sends my data up to the cloud automatically for an offsite backup. This way, if I need to recover just one piece of data, I can grab it off the hardware device. But if I have a major issue, such as a fire that destroys the entire server room, I have an offsite backup from which I can retrieve my data.

It’s the same for GPOs. You need to make sure you back up your GPOs in the event of an issue that requires you to do a reload. To back up your GPOs manually, you can go into the GPMC MMC and, under Group Policy Objects, you can right click and choose Backup All or right click on the specific GPO and choose Backup.

Restoring a GPO

There may be times when you have to restore a GPO that was previously backed up. There are normally two reasons why you have to restore a GPO—you accidently deleted the GPO, or you need to restore the GPO to a previous state. (This normally happens if you make changes and it causes an issue.) Restoring a GPO is simple.

1. Open the Group Policy Management Console.

2. In the console tree, right-click Group Policy Objects and choose Manage Backups.

3. Choose the backup you want to restore and click the Restore button.

Importing or Copying GPOs

As an administrator, there may be times when you need to import or copy a GPO from one domain to another domain. Administrators do this so that the second domain has the same settings as the first domain.

An administrator can use the import or copy-to-transfer settings from one GPO to another GPO within the same domain, to a GPO in another domain in the same forest, or to a GPO in a domain in a different forest.

Importing or copying a GPO is an easy process. To do this, an administrator completes the following steps:

1. Open the Group Policy Management Console.

2. In the console tree, right-click Group Policy Objects and choose either Import Settings or Copy.

Migration Tables

One issue that we run into when copying or moving a GPO from one system to another is that when some GPOs are built, they are domain specific. This can be a problem when they are moved to a system in another domain. This is where migration tables can help you out.

Migration tables will tell you how domain specific settings should be treated when the GPO is moved from the domain in which it was created to another domain.

Migration tables are files that are used to map previous domain information (such as users and groups) to the new domain’s object-specific data. Migration tables have mapping entries that map the old data to the new data.

Migration tables store their mapping data in an XML format, and the migration tables have their own extension name, .migtable. If you want to create your own migration table, you can use the Migration Table Editor (MTE). The MTE is an easy-to-use utility for configuring or just viewing migration tables.

It does not matter if you decide to copy or import a GPO, migration tables apply to any of the settings within the GPO. However, if you copy a GPO instead of move it, you have the option of bringing the Discretionary Access Control List (DACL) option over with the copy.

If you are looking at using migration tables, there are three settings that can be used:

Do Not Use A Migration Table If an administrator chooses this option, the GPO is copied over exactly as is. All security objects and UNC paths are copied over without any modification.

Use A Migration Table If an administrator chooses this option, the GPO has all of the options that can be in the migration table mapped.

Use A Migration Table Exclusively If an administrator chooses this option, all security principals and UNC path information in the GPO are chosen. If any of this information is not included in the migration table, the operation will fail.

To open the Migration Table Editor, perform the following steps:

1. Open the Group Policy Management Console.

2. In the console tree, right-click Group Policy Objects and choose Open Migration Table Editor.

Resetting the Default GPO

There may be a time when you need to reset the default GPO to its original settings. This is easy to do as long as you understand how to use the DCGPOFix command-line utility. This command-line utility is just what it spells—it fixes the domain controller’s GPO. To use this command, you would use the following syntax:

DCGPOFix [/ignoreschema] [/target: {Domain | DC | Both}] [/?]

So, let’s take a look at the switches in the previous command. The /ignoreschema switch ignores the current version of the Active Directory Schema. The reason you use this switch is because this command works only on the same schema version as the Windows version in which the command was shipped. By using this switch, you don’t need to worry about what schema you have on the system.

The next switch is [/target: {Domain | DC | Both}]. This switch specifies the GPO you are going to restore. An administrator has the ability to restore the Default Domain Policy GPO, the Default Domain Controllers GPO, or both. The final switch, /?, displays the help for this command.

Deploying Software Through a GPO

It’s difficult enough to manage applications on a stand-alone computer. It seems that the process of installing, configuring, and uninstalling applications is never finished. Add in the hassle of computer reboots and reinstalling corrupted applications, and the reduction in productivity can be substantial.

Software administrators who manage software in network environments have even more concerns:

§ First and foremost, they must determine which applications specific users require.

§ Then IT departments must purchase the appropriate licenses for the software and acquire any necessary media.

§ Next, the system administrators need to install the applications on users’ machines. This process generally involves help desk staff visiting computers, or it requires end users to install the software themselves. Both processes entail several potential problems, including installation inconsistency and lost productivity from downtime experienced when the applications were installed.

§ Finally, software administrators still need to manage software updates and remove unused software.

One of the key design goals for Active Directory was to reduce some of the headaches involved in managing software and configurations in a networked environment. To that end, Windows Server 2012 R2 offers several features that can make the task of deploying software easier and less error prone. Before you dive into the technical details, however, you need to examine the issues related to software deployment.

The Software Management Life Cycle

Although it may seem that the use of a new application requires only the installation of the necessary software, the overall process of managing applications involves many more steps. When managing software applications, there are three main phases to their life cycle:

Phase 1: Deploying Software The first step in using applications is to install them on the appropriate client computers. Generally, some applications are deployed during the initial configuration of a PC, and others are deployed when they are requested. In the latter case, this often meant that system administrators and help desk staffs had to visit client computers and manually walk through the installation process. With Windows Server 2012 R2 and GPOs, the entire process can be automated.

Before You Install, Stop

It is important to understand that just because you can easily deploy software, it does not necessarily mean that you have the right to do so. Before you install software on client computers, you must make sure you have the appropriate licenses for the software. Furthermore, it’s important to take the time to track application installations. As many system administrators have discovered, it’s much more difficult to inventory software installations after they’ve been performed. Another issue you may encounter is that you lack available resources (for instance, your system does not meet the minimum hardware requirements) and face problems such as limited hard disk space or memory that may not be able to handle the applications that you want to load and use. You may also find that your user account does not have the permission to install software. It’s important to consider not only how you will install software but also whether you can or not.

Phase 2: Maintaining Software Once an application is installed and in use on client computers, you need to ensure that the software is maintained. You must keep programs up-to-date by applying changes due to bug fixes, enhancements, and other types of updates. This is normally done with service packs, hot fixes, and updates. As with the initial software deployment, software maintenance can be tedious. Some programs require older versions to be uninstalled before updates are added. Others allow for automatically upgrading over existing installations. Managing and deploying software updates can consume a significant amount of the IT staff’s time.

Using Windows Update

Make sure you learn about Windows Update, a service that allows you to connect to Microsoft’s website and download what your system may need to bring it up to compliance. This tool is helpful if you are running a stand-alone system, but if you want to deploy software across the enterprise, the best way to accomplish this is first to test the updates you are downloading and make sure you can use them and that they are not bug ridden. Then you can use a tool such as the Windows Server Update Service (WSUS), which was formerly called the Software Update Services (SUS).

You can check for updates at Microsoft’s website (http://update.microsoft.com). Microsoft likes to ask many types of questions about WSUS on its certification exams. WSUS is described in detail in other Sybex certification series books.

Phase 3: Removing Software The end of the life cycle for many software products involves the actual removal of unused programs. Removing software is necessary when applications become outdated or when users no longer require their functionality. One of the traditional problems with uninstalling applications is that many of the installed files may not be removed. Furthermore, removing shared components can sometimes cause other programs to stop functioning properly. Also, users often forget to uninstall applications that they no longer need, and these programs continue to occupy disk space and consume valuable system resources.

The Microsoft Windows Installer (MSI) manages each of these three phases of the software maintenance life cycle. Now that you have an overview of the process, let’s move forward to look at the steps involved in deploying software using Group Policy.

image The Microsoft Windows Installer (sometimes referred to as Microsoft Installer or Windows Installer) is an application installation and configuration service. An instruction file (the Microsoft Installer package) contains information about what needs to be done to install a product. It’s common to confuse the two.

The Windows Installer

If you’ve installed newer application programs (such as Microsoft Office 2013), you’ve probably noticed the updated setup and installation routines. Applications that comply with the updated standard use the Windows Installer specification and MSI software packages for deployment. Each package contains information about various setup options and the files required for installation. Although the benefits may not seem dramatic on the surface, there’s a lot of new functionality under the hood.

The Windows Installer was created to solve many of the problems associated with traditional application development. It has several components, including the Installer service (which runs on Windows 2000, XP, Vista, Windows 7, Windows 8, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 R2 computers), the Installer program (msiexec.exe) that is responsible for executing the instructions in a Windows Installer package, and the specifications third-party developers use to create their own packages. Within each installation package file is a relational structure (similar to the structure of tables in databases) that records information about the programs contained within the package.

To appreciate the true value of the Windows Installer, you’ll need to look at some of the problems with traditional software deployment mechanisms and then at how the Windows Installer addresses many of them.

Application Installation Issues

Before the Windows Installer, applications were installed using a setup program that managed the various operations required for a program to operate. These operations included copying files, changing registry settings, and managing any other operating system changes that might be required (such as starting or stopping services). However, this method had several problems:

§ The setup process was not robust, and aborting the operation often left many unnecessary files in the file system.

§ The process included uninstalling an application (this also often left many unnecessary files in the file system) and remnants in the Windows registry and operating system folders. Over time, these remnants would result in reduced overall system performance and wasted disk space.

§ There was no standard method for applying upgrades to applications, and installing a new version often required users to uninstall the old application, reboot, and then install the new program.

§ Conflicts between different versions of dynamic link libraries (DLLs)—shared program code used across different applications—could cause the installation or removal of one application to break the functionality of another.

Benefits of the Windows Installer

Because of the many problems associated with traditional software installation, Microsoft created the Windows Installer. This system provides for better manageability of the software installation process and gives system administrators more control over the deployment process. Specifically, the Windows Installer provides the following benefits:

Improved Software Removal The process of removing software is an important one because remnants left behind during the uninstall process can eventually clutter up the registry and file system. During the installation process, the Windows Installer keeps track of all of the changes made by a setup package. When it comes time to remove an application, all of these changes can then be rolled back.

More Robust Installation Routines If a typical setup program is aborted during the software installation process, the results are unpredictable. If the actual installation hasn’t yet begun, then the installer generally removes any temporary files that may have been created. However, if the file copy routine starts before the system encounters an error, it is likely that the files will not be removed automatically from the operating system. In contrast, the Windows Installer allows you to roll back any changes when the application setup process is aborted.

Ability to Use Elevated Privileges Installing applications usually requires the user to have Administrator permissions on the local computer because file system and registry changes are required. When installing software for network users, system administrators have two options. First they can log off of the computer before installing the software and then log back on as a user who has Administrator permissions on the local computer. This method is tedious and time-consuming. The second option is to give users Administrator permissions temporarily on their own machines. This method could cause security problems and requires the attention of a system administrator.

Through the use of the Installer service, the Windows Installer is able to use temporarily elevated privileges to install applications. This allows users, regardless of their security settings, to execute the installation of authorized applications. This saves time and preserves security.

Support for Repairing Corrupted Applications Regardless of how well a network environment is managed, critical files are sometimes lost or corrupted. Such problems can prevent applications from running properly and can cause crashes. Windows Installer packages provide you with the ability to verify the installation of an application and, if necessary, replace any missing or corrupted files. This support saves time and lessens end-user headaches associated with removing and reinstalling an entire application to replace just a few files.

Prevention of File Conflicts Generally, different versions of the same files should be compatible with each other. In the real world, however, this isn’t always the case. A classic problem in the Windows world is the case of one program replacing DLLs that are used by several other programs. Windows Installer accurately tracks which files are used by certain programs and ensures that any shared files are not improperly deleted or overwritten.

Automated Installations A typical application setup process requires end users or system administrators to respond to several prompts. For example, a user may be able to choose the program group in which icons will be created and the file system location to which the program will be installed. Additionally, they may be required to choose which options are installed. Although this type of flexibility is useful, it can be tedious when you are rolling out multiple applications. By using features of the Windows Installer, however, users are able to specify setup options before the process begins. This allows system administrators to ensure consistency in installations, and it saves users’ time.

Advertising and On-Demand Installations One of the most powerful features of the Windows Installer is its ability to perform on-demand software installations. Prior to the Windows Installer, application installation options were quite basic—either a program was installed or it was not. When setting up a computer, system administrators would be required to guess which applications the user might need and install all of them.

The Windows Installer supports a function known as advertising. Advertising makes applications appear to be available via the Start menu. However, the programs themselves may not actually be installed on the system. When a user attempts to access an advertised application, the Windows Installer automatically downloads the necessary files from a server and installs the program. The result is that applications are installed only when they are needed, and the process requires no intervention from the end user. We’ll cover the details of this process later in this chapter.

To anyone who has managed many software applications in a network environment, all of these features of the Windows Installer are likely welcome ones. They also make life easier for end users and applications developers; they can focus on the “real work” that their jobs demand.

Windows Installer File Types

When performing software deployment with the Windows Installer in Windows Server 2012 R2, you may encounter several different file types:

Microsoft Windows Installer Packages To take full advantage of Windows Installer functionality, applications must include Microsoft Windows Installer (MSI) packages. Third-party application vendors and software developers normally create these packages, and they include the information required to install and configure the application and any supporting files.

Microsoft Transformation Files Microsoft Transformation (MST) files are useful when you are customizing the details of how applications are installed. When a system administrator chooses to assign or publish an application, they may want to specify additional options for the package. For example, if a system administrator wants to allow users to install only the Microsoft Word and Microsoft PowerPoint components of Office 2013, they could specify these options within a transformation file. Then, when users install the application, they will be provided only with the options related to these components.

Microsoft Patches To maintain software, patches are often required. Patches may make registry and/or file system changes. Patch files (MSP) are used for minor system changes and are subject to certain limitations. Specifically, a patch file cannot remove any installed program components and cannot delete or modify any shortcuts created by the user.

Initialization Files To provide support for publishing non–Windows Installer applications, initialization files can be used. These files provide links to a standard executable file that is used to install an application. An example might be\\server1\software\program1\setup.exe. These files can then be published and advertised, and users can access the Programs and Features icon to install them over the network.

Application Assignment Scripts Application assignment scripts (AAS) store information regarding assigning programs and any settings that the system administrator makes. These files are created when Group Policy is used to create software package assignments for users and computers.

Each of these types of files provides functionality that allows the system administrator to customize software deployment. Windows Installer packages have special properties that you can view by right-clicking the file in Windows Explorer and choosing Properties (see Figure 7.9).

image

FIGURE 7.9 Viewing the properties of an MSI package file

Deploying Applications

The functionality provided by Windows Installer offers many advantages to end users who install their own software. However, that is just the beginning in a networked environment. As you’ll see later in this chapter, the various features of Windows Installer and compatible packages allow system administrators to determine centrally which applications users will be able to install.

There are two main methods of making programs available to end users using Active Directory: assigning and publishing. Both assigning and publishing applications greatly ease the process of deploying and managing applications in a network environment.

In the following sections, you’ll look at how the processes of assigning and publishing applications can make life easier for IT staff and users alike. The various settings for assigned and published applications are managed through the use of GPOs.

Assigning Applications

Software applications can be assigned to users and computers. Assigning a software package makes the program available for automatic installation. The applications advertise their availability to the affected users or computers by placing icons within the Programsfolder of the Start menu.

When applications are assigned to a user, programs will be advertised to the user regardless of which computer they are using. That is, icons for the advertised program will appear within the Start menu regardless of whether the program is installed on that computer. If the user clicks an icon for a program that has not yet been installed on the local computer, the application will automatically be accessed from a server and it will be installed.

When an application is assigned to a computer, the program is made available to any users of the computer. For example, all users who log on to a computer that has been assigned Microsoft Office 2013 will have access to the components of the application. If the user did not previously install Microsoft Office 2013, they will be prompted for any required setup information when the program first runs.

Generally, applications that are required by the vast majority of users should be assigned to computers. This reduces the amount of network bandwidth required to install applications on demand and improves the end-user experience by preventing the delay involved when installing an application the first time it is accessed. Any applications that may be used by only a few users (or those with specific job tasks) should be assigned to users.

Publishing Applications

When applications are published, they are advertised, but no icons are automatically created. Instead, the applications are made available for installation using the Add Or Remove Programs icon in Control Panel.

image Windows Vista, Windows 7, and Windows 8 do not have the Add Or Remove Programs feature. They use the Programs and Features icon in Control Panel to install the software.

Implementing Software Deployment

So far, you have become familiar with the issues related to software deployment and management from a theoretical level. Now it’s time to drill down into the actual steps required to deploy software using the features of Active Directory and the GPMC. In the following sections, you will walk through the steps required to create an application distribution share point, to publish and assign applications, to update previously installed applications, to verify the installation of applications, and to update Windows operating systems.

Preparing for Software Deployment

Before you can install applications on client computers, you must make sure that the necessary files are available to end users. In many network environments, system administrators create shares on file servers that include the installation files for many applications. Based on security permissions, either end users or system administrators can then connect to these shares from a client computer and install the needed software. The efficient organization of these shares can save the help desk from having to carry around a library of CD-ROMs, and it allows you to install applications easily on many computers at once.

image One of the problems in network environments is that users frequently install applications whether or not they really need them. They may stumble upon applications that are stored on common file servers and install them out of curiosity. These actions can often decrease productivity and may violate software licensing agreements. You can help to avoid this by placing all of your application installation files in hidden shares (for example, software$).

Exercise 7.7 walks you through the process of creating a software distribution share point. In this exercise, you will prepare for software deployment by creating a directory share and placing certain types of files in this directory. To complete the steps in this exercise, you must have access to the Microsoft Office 2010 or Microsoft Office 2013 installation files (via CD-ROM or through a network share) and have 2000MB of free disk space. For this exercise, I used Microsoft Office 2010.

image EXERCISE 7.7: Creating a Software Deployment Share

1. Using Windows Explorer, create a folder called Software that you can use with application sharing. Be sure that the volume on which you create this folder has at least 2000MB of available disk space.

2. Create a folder called Office 2010 within the Software folder.

3. Copy all the installation files for Microsoft Office 2010 from the CD-ROM or network share containing the files to the Office 2010 folder you created in step 2. If you prefer, you can use switches to install all the Office 2010 installation files. You can find these switches at http://technet.microsoft.com/en-us/library/ff521767.aspx.

4. Right-click the Software folder (created in step 1) and select Share. In the Choose People On Your Network To Share With dialog box, type Everyone and click the Add button. Next click the Share button. When you see a message that the sharing process is complete, click Done.

Once you have created an application distribution share, it’s time to publish and assign the applications. This topic is covered next.

Software Restriction Policies

One of the biggest problems that we face as IT managers is that of users downloading and installing software. Many software packages don’t cause any issues and are completely safe. Unfortunately, many software packages do have viruses and can cause problems. This is where software restriction policies can help. Software restriction policies help to identify software and to control its ability to run on a local computer, organizational unit, domain, or site.

Software restriction policies give administrators the ability to regulate unknown or untrusted software. Software restriction policies allow you to protect your computers from unwanted software by identifying and also specifying what software packages are allowed to be installed.

When configuring software restriction policies, an administrator is able to define a default security level of Unrestricted (software is allowed) or Disallowed (software is not allowed to run) for a GPO. Administrators can make exceptions to this default security level. They can create software restriction policy rules for specific software.

To create a software policy using the Group Policy Management Console, create a new GPO. In the GPO, expand the Windows Settings for either the user or computer configuration section, expand Security, right-click Software Restriction Policy, and choose New Software Restriction Policy. Set the policy for the level of security that you need.

Using AppLocker

AppLocker is a feature in Windows 7, Windows 8, and Windows Server 2012 R2. It is the replacement for Software Restriction Policies. AppLocker allows you to configure a Denied list and an Accepted list for applications. Applications that are configured on the Denied list will not run on the system, whereas applications on the Accepted list will operate properly.

The new capabilities and extensions of the AppLocker feature help reduce administrative overhead and help administrators control how users can access and use files, such as EXE files, scripts, Windows Installer files (MSI and MSP files), and DLLs.

Group Policy Slow Link Detection

When setting up GPOs, most of us assume that the connection speeds between servers and clients are going to be fast. In today’s world, it is unlikely to see slow connections between locations, but they are still out there. Sometimes connection speeds can cause issues with the deployment of GPOs, specifically ones that are deploying software.

A setting in the Computer and User section of the GPO called Group Policy Slow Link Detection defines a slow connection for the purposes of applying and updating GPOs. If the data transfer rate from the domain controller providing the GPO to the computer is slower than what you have specified in this setting, the connection is considered to be a slow connection. If a connection is considered slow, the system response will vary depending on the policy. For example, if a GPO is going to deploy software and the connection is considered slow, the software may not be installed on the client computer. If you configure this option as 0, all connections are considered fast connections.

Publishing and Assigning Applications

As mentioned earlier in this section, system administrators can make software packages available to users by using publishing and assigning operations. Both of these operations allow system administrators to leverage the power of Active Directory and, specifically,GPOs to determine which applications are available to users. Additionally, OUs can provide the organization that can help group users based on their job functions and software requirements.

The general process involves creating a GPO that includes software deployment settings for users and computers and then linking this GPO to Active Directory objects.

Exercise 7.8 walks you through the steps required to publish and assign applications. In this exercise, you will create applications and assign them to specific Active Directory objects using GPOs. To complete the steps in this exercise, you must have completedExercise 7.7.

image EXERCISE 7.8: Publishing and Assigning Applications Using Group Policy

1. Open the Active Directory Users and Computers tool from the Administrative Tools program group (using the Windows key).

2. Expand the domain and create a new top-level OU called Software.

3. Within the Software OU, create a user named Jane User with a login name of juser (choose the defaults for all other options).

4. Exit Active Directory Users and Computers and open the Group Policy Management Console.

5. Right-click the Software OU and choose Create A GPO In This Domain And Link It Here.

6. For the name of the new GPO, type Software Deployment.

7. To edit the Software Deployment GPO, right-click it and choose Edit. Expand the Computer Configuration ⇒ Policies ⇒ Software Settings object.

8. Right-click the Software Installation item and select New ⇒ Package.

9. Navigate to the Software share you created in Exercise 7.7.

10.Within the Software share, double-click the Office 2010 folder and select the appropriate MSI file depending on the version of Office 2010 that you have. Office 2010 Professional is being used in this example, so you’ll see that the OFFICEMUI.MSI file is chosen. Click Open.

11.In the Deploy Software dialog box, choose Advanced. (Note that the Published option is unavailable because applications cannot be published to computers.) Click OK to return to the Deploy Software dialog box.

12.To examine the deployment options of this package, click the Deployment tab. Accept the default settings by clicking OK.

13.Within the Group Policy Object Editor, expand the User Configuration ⇒ Software Settings object.

14.Right-click the Software Installation item and select New ⇒ Package.

15.Navigate to the Software share you created in Exercise 7.7.

16.Within the Software share, double-click the Office 2010 folder and select the appropriate MSI file. Click Open.

17.For the Software Deployment option, select Published in the Deploy Software dialog box and click OK.

18.Close the GPMC.

The overall process involved in deploying software using Active Directory is quite simple. However, you shouldn’t let the intuitive graphical interface fool you—there’s a lot of power under the hood of these software deployment features! Once you’ve properly assigned and published applications, it’s time to see the effects of your work.

Applying Software Updates

The steps described in the previous section work only when you are installing a new application. However, software companies often release updates that you need to install on top of existing applications. These updates usually consist of bug fixes or other changes that are required to keep the software up-to-date. You can apply software updates in Active Directory by using the Upgrades tab of the software package Properties dialog box found in the Group Policy Object Editor.

In Exercise 7.9, you will apply a software update to an existing application. You should add the upgrade package to the GPO in the same way that you added the original application in steps 8 through 12 of Exercise 7.8. You should also have completed Exercise 7.8before attempting this exercise.

EXERCISE 7.9: Applying Software Updates

1. Open the Group Policy Management Console from the Administrative Tools program group.

2. Click the Software OU, right-click the Software Deployment GPO, and choose Edit.

3. Expand the Computer Configuration ⇒ Policies ⇒ Software Settings ⇒ Software Installation object.

4. Right-click the software package and select Properties from the context menu to bring up the Properties dialog box.

5. Select the Upgrades tab and click the Add button.

6. Click the Current Group Policy Object (GPO) radio button in the Choose A Package From section of the dialog box or click the Browse button to select the GPO to which you want to apply the upgrade. Consult your application’s documentation to see whether you should choose the Uninstall The Existing Package, the Install The Upgrade Package radio button, or the Package Can Upgrade Over The Existing Package radio button.

7. Click Cancel to close the Add Upgrade Package dialog box.

8. Click Cancel and exit the GPMC.

You should understand that not all upgrades make sense in all situations. For instance, if the Stellacon 2010 files are incompatible with the Stellacon 2013 application, then your Stellacon 2012 users might not want you to perform the upgrade without taking additional steps to ensure that they can continue to use their files. In addition, users might have some choice about which version they use when it doesn’t affect the support of the network.

Regardless of the underlying reason for allowing this flexibility, you should be aware that there are two basic types of upgrades that are available for administrators to provide to users:

Mandatory Upgrade Forces everyone who currently has an existing version of the program to upgrade according to the GPO. Users who have never installed the program for whatever reason will be able to install only the new upgraded version.

Nonmandatory Upgrade Allows users to choose whether they would like to upgrade. This upgrade type also allows users who do not have their application installed to choose which version they would like to use.

Verifying Software Installation

To ensure that the software installation settings you make in a GPO have taken place, you can log into the domain from a Windows 8, Windows 7, or Windows Vista computer that is within the OU to which the software settings apply. When you log in, you will notice two changes. First the application is installed on the computer (if it was not installed already). To access the application, a user needs to click one of the icons within the Program group of the Start menu. Note also that applications are available to any of the users who log on to this machine. Second, the settings apply to any computers that are contained within the OU and to any users who log on to these computers.

If you publish an application to users, the change may not be as evident, but it is equally useful. When you log on to a Windows 8, Windows 7, or Windows Vista computer that is a member of the domain, and when you use a user account from the OU where you published the application, you will be able to install any of the published applications automatically. On a Windows 8 or Windows 7 computer, you can do this by accessing the Programs icon in Control Panel. By clicking Add New Programs, you access a display of the applications available for installation. By clicking the Add button in the Programs and Features section of the Programs dialog box, you will automatically begin the installation of the published application.

Configuring Automatic Updates in Group Policy

So far you’ve seen the advantages of deploying application software in a group policy. Group policies also provide a way to install operating system updates across the network for Windows 2000, XP, Vista, Windows 7, Windows 8, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 R2 machines using Windows Update in conjunction with Windows Server Update Service. WSUS is the newer version of SUS, and it is used on a Windows Server 2012 R2 system to update systems. As you may remember, WSUS and SUS are patch-management tools that help you deploy updates to your systems in a controlled manner.

Windows Update is available through the Microsoft website, and it is used to provide the most current files for Windows operating systems. Examples of updates include security fixes, critical updates, updated help files, and updated drivers. You can access Windows Update by clicking the Windows Update icon in the system tray.

image We will discuss WSUS in greater detail in Chapter 1, “Manage and Maintain Servers.”

WSUS is used to leverage the features of Windows Update within a corporate environment by downloading Windows updates to a corporate server, which in turn provides the updates to the internal corporate clients. This allows administrators to test and have full control over what updates are deployed within the corporate environment.

Within an enterprise network that is using Active Directory, you would typically see automatic updates configured through Group Policy. Group policies are used to manage configuration and security settings via Active Directory. Group Policy is also used to specify what server a client will use for automatic updates.

If the WSUS client is part of an enterprise network that is using Active Directory, you would configure the client via a group policy.

Configuring Software Deployment Settings

In addition to the basic operations of assigning and publishing applications, you can use several other options to specify the details of how software is deployed. In the following sections, you will examine the various options that are available and their effects on the software installation process.

The Software Installation Properties Dialog Box

The most important software deployment settings are contained in the Software Installation Properties dialog box, which you can access by right-clicking the Software Installation item and selecting Properties from the context menu. The following sections describe the features contained on the various tabs of the dialog box.

Managing Package Defaults

On the Deployment tab of the Software Installation Properties dialog box, you’ll be able to specify some defaults for any packages that you create within this GPO. Figure 7.10 shows the Deployment options for managing software installation settings.

image

FIGURE 7.10 Deployment tab of the Software Installation Properties dialog box

The following options are used for managing software installation settings:

Default Package Location This setting specifies the default file system or network location for software installation packages. This is useful if you are already using a specific share on a file server for hosting the necessary installation files.

New Packages These settings specify the default type of package assignment that will be used when you add a new package to either the user or computer settings. If you’ll be assigning or publishing multiple packages, you may find it useful to set a default here. Selecting the Advanced option enables Group Policy to display the package’s Properties dialog box each time a new package is added (see Figure 7.11).

image

FIGURE 7.11 Advanced Deployment dialog box

Installation User Interface Options When installing an application, system administrators may or may not want end users to see all of the advanced installation options. If Basic is chosen, the user will only be able to configure the minimal settings (such as the installation location). If Maximum is chosen, all of the available installation options will be displayed. The specific installation options available will depend on the package itself.

Uninstall Applications When They Fall Out of the Scope of Management So far, you have seen how applications can be assigned and published to users or computers. But what happens when effective GPOs change? For example, suppose User A is currently located within the Sales OU. A GPO that assigns the Microsoft Office 2013 suite of applications is linked to the Sales OU. You decide to move User A to the Engineering OU, which has no software deployment settings. Should the application be uninstalled, or should it remain?

If the Uninstall This Application When It Falls Out Of The Scope Of Management option is checked, applications will be removed if they are not specifically assigned or published within GPOs. In this example, this means that Office 2013 would be uninstalled for User A. If this box is left unchecked, however, the application will remain installed.

Managing File Extension Mappings

One of the potential problems associated with using many different file types is that it’s difficult to keep track of which applications work with which files. For example, if you received a file with the filename extension .abc, you would have no idea which application you would need to view it.

Fortunately, through software deployment settings, system administrators can specify mappings for specific filename extensions. For example, you could specify that whenever users attempt to access a file with the extension .vsd, the operating system should attempt to open the file using Visio diagramming software. If Visio is not installed on the user’s machine, the computer can automatically download and install it (assuming that the application has been properly advertised).

This method allows users to have applications automatically installed when they are needed. The following is an example of a sequence of events that might occur:

1. A user receives an email message that contains a PDF (.pdf) file attachment.

2. The computer realizes that the PDF file does not have the appropriate viewing application for this type of file installed. However, it also realizes that a filename extension mapping is available within the Active Directory software deployment settings.

3. The client computer automatically requests the PDF software package from the server, and it uses the Microsoft Windows Installer to install the application automatically.

4. The computer opens the attachment for the user.

Notice that all of these steps were carried out without any further interaction with the user.

You can manage filename extension mappings by right-clicking the Software Installation item, selecting Properties, and then clicking the File Extensions tab.

Creating Application Categories

In many network environments, the list of supported applications can include hundreds of items. For users who are looking for only one specific program, searching through a list of all of these programs can be difficult and time-consuming.

Fortunately, methods for categorizing the applications are available on your network. You can easily manage the application categories for users and computers by right-clicking the Software Installation item, selecting Properties, and then clicking the Categories tab.

Figure 7.12 shows you the categories tab of the Software Installation package. When creating categories, it is a good idea to use category names that are meaningful to users because it will make it easier for them to find the programs they’re seeking.

image

FIGURE 7.12 The Categories tab of the Software Installation Properties dialog box

Once the software installation categories have been created, you can view them by clicking the Programs or Programs And Features icon in Control Panel. When you click Add New Programs, you’ll see that several options appear in the Category drop-down list. Now when you select the properties for a package, you will be able to assign the application to one or more of the categories.

Removing Programs

As discussed in the beginning of the chapter, an important phase in the software management life cycle is the removal of applications. Fortunately, if you use the GPMC and the Windows Installer packages, the process is simple. To remove an application, you can right-click the package within the Group Policy settings and select All Tasks ⇒Remove (see Figure 7.13).

image

FIGURE 7.13 Removing a software package

When choosing to remove a software package from a GPO, you have two options:

Immediately Uninstall The Software From Users And Computers System administrators can choose this option to ensure that an application is no longer available to users who are affected by the GPO. When this option is selected, the program will be uninstalled automatically from users and/or computers that have the package. This option might be useful, for example, if the license for a certain application has expired or if a program is no longer on the approved applications list.

Allow Users To Continue To Use The Software, But Prevent New Installations This option prevents users from making new installations of a package, but it does not remove the software if it has already been installed for users. This is a good option if the company has run out of additional licenses for the software, but the existing licenses are still valid.

Figure 7.14 shows these two removal options.

image

FIGURE 7.14 Software removal options

If you no longer require the ability to install or repair an application, you can delete it from your software distribution share point by deleting the appropriate Windows Installer package files. This will free up additional disk space for newer applications.

Microsoft Windows Installer Settings

Several options influence the behavior of the Windows Installer; you can set them within a GPO. You can access these options by navigating to User Configuration ⇒Administrative Templates ⇒ Windows Components ⇒ Windows Installer (see Figure 7.15). The options are as follows:

image

FIGURE 7.15 GPO settings for Windows Installer

Always Install With Elevated Privileges This policy allows users to install applications that require elevated privileges. For example, if a user does not have the permissions necessary to modify the registry but the installation program must make registry changes, this policy will allow the process to succeed.

Prevent Removable Media Source For Any Install This option disallows the installation of software using removable media (such as CD-ROM or DVD-ROM). It is useful for ensuring that users install only approved applications.

Prohibit Rollback When this option is enabled, the Windows Installer does not store the system state information that is required to roll back the installation of an application. System administrators may choose this option to reduce the amount of temporary disk space required during installation and to increase the performance of the installation operation. However, the drawback is that the system cannot roll back to its original state if the installation fails and the application needs to be removed.

Specify the Order In Which Windows Installer Searches This setting specifies the order in which the Windows Installer will search for installation files. The options include n (for network shares), m (for searching removal media), and u (for searching the Internet for installation files).

With these options, system administrators can control how the Windows Installer operates for specific users who are affected by the GPO.

Troubleshooting Group Policies

Because of the wide variety of configurations that are possible when you are establishing GPOs, you should be aware of some common troubleshooting methods. These methods will help isolate problems in policy settings or GPO links.

One possible problem with GPO configuration is that logons and system startups may take a long time. This occurs especially in large environments when the Group Policy settings must be transmitted over the network and, in many cases, slow WAN links. In general, the number of GPOs should be limited because of the processing overhead and network requirements during logon. By default, GPOs are processed in a synchronous manner. This means that the processing of one GPO must be completed before another one is applied (as opposed to asynchronous processing, where they can all execute at the same time).

When a group policy gets processed on a Windows-based operating system, client-side extensions are the mechanisms that interpret the stored policy and then make the appropriate changes to the operating system environment. When an administrator is troubleshooting a given extension’s application of policy, the administrator can view the configuration parameters for that extension in the operating system’s registry. To view the extension in the registry, you would view the following key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows CA

NT\CurrentVersion\Winlogon\GPExtensions

The most common issue associated with Group Policy is the unexpected setting of Group Policy options. In Windows Server 2000, administrators spent countless hours analyzing inheritance hierarchy and individual settings to determine why a particular user or computer was having policy problems. For instance, say a user named wpanek complains that the Run option is missing from his Start menu. The wpanek user account is stored in the New Hampshire OU, and you’ve applied group policies at the OU, domain, and site levels. To determine the source of the problem, you would have to sift through each GPO manually to find the Start menu policy as well as to figure out the applicable inheritance settings.

Windows Server 2012 R2 has a handy feature called Resultant Set of Policy (RSoP) that displays the exact settings that actually apply to individual users, computers, OUs, domains, and sites after inheritance and filtering have taken effect. In the example just described, you could run RSoP on the wpanek account and view a single set of Group Policy settings that represent the settings that apply to the wpanek account. In addition, each setting’s Properties dialog box displays the GPO from which the setting is derived as well as the order of priority, the filter status, and other useful information, as you will see a bit later.

RSoP actually runs in two modes:

Logging Mode Logging mode displays the actual settings that apply to users and computers, as shown in the example in the preceding paragraph.

Planning Mode Planning mode can be applied to users, computers, OUs, domains, and sites, and you use it before you apply any settings. As its name implies, planning mode is used to plan GPOs.

Additionally, you can run the command-line utility gpresult.exe to get a quick snapshot of the Group Policy settings that apply to a user and/or computer. Let’s take a closer look at the two modes and the gpresult.exe command.

RSoP in Logging Mode

RSoP in logging mode can query policy settings only for users and computers. The easiest way to access RSoP in logging mode is through the Active Directory Users and Computers tool, although you can run it as a stand-alone MMC snap-in if you want.

To analyze the policy settings for wpanek from the earlier example, you would right-click the user icon in Active Directory Users and Computers and select All Tasks ⇒Resultant Set of Policy (Logging). The Group Policy Results Wizard appears. The wizard walks you through the steps necessary to view the RSoP for wpanek.

The Computer Selection page, shown in Figure 7.16, requires you to select a computer for which to display settings. Remember that a GPO contains both user and computer settings, so you must choose a computer to which the user is logged on in order to continue with the wizard. If the user has never logged on to a computer, then you must run RSoP in planning mode because there is no logged policy information yet for that user.

image

FIGURE 7.16 The Computer Selection page of the Group Policy Results Wizard

The User Selection page, shown in Figure 7.17, requires you to select a user account to analyze. Because I selected a user from the Active Directory Users and Computers tool, the username is filled in automatically. This page is most useful if you are running RSoP in MMC mode and don’t have the luxury of selecting a user contextually.

image

FIGURE 7.17 The User Selection page of the Group Policy Results Wizard

The Summary Of Selections page, shown in Figure 7.18, displays a summary of your choices and provides an option for gathering extended error information. If you need to make any changes before you begin to analyze the policy settings, you should click the Back button on the Summary screen. Otherwise, click Next.

image

FIGURE 7.18 The Summary Of Selections page of the Group Policy Results Wizard

After the wizard is complete, you will see the window shown in Figure 7.19. This window displays only the policy settings that apply to the user and computer that you selected in the wizard. You can see these users and computers at the topmost level of the tree.

image

FIGURE 7.19 The User Selection page for the administrator on computer SERVER1

Any warnings or errors appear as a yellow triangle or red X over the applicable icon at the level where the warning or error occurred. To view more information about the warning or error, right-click the icon, select Properties, and select the Error Information tab.Figure 7.20 shows an error message.

image

FIGURE 7.20 Details of event pertaining to the administrator account on computer SERVER1

You cannot make changes to any of the individual settings because RSoP is a diagnostic tool and not an editor, but you can get more information about settings by clicking a setting and selecting Properties from the context menu.

The Details tab of the user’s Properties window, shown in Figure 7.21, displays the actual setting that applies to the user in question based on GPO inheritance.

image

FIGURE 7.21 The Details tab of the object’s Properties window

RSoP in Planning Mode

Running RSoP in planning mode isn’t much different from running RSoP in logging mode, but the RSoP Wizard asks for a bit more information than you saw earlier.

In the former example, wpanek couldn’t see the Run option in the Start menu because the New Hampshire GPO in the San Jose OU affects his user account. As an administrator, you could plan to move his user account to the North America OU. Before doing so, you could verify his new policy settings by running RSoP in planning mode. Run the RSoP on the user wpanek under the scenario that you’ve already moved him from the San Jose OU to the North America OU. At this point, you haven’t actually moved the user, but you can see what his settings would be if you did.

Using the gpresult.exe Command

The command-line utility gpresult.exe is included as part of the RSoP tool. Running the command by itself without any switches returns the following Group Policy information about the local user and computer:

§ The name of the domain controller from which the local machine retrieved the policy information

§ The date and time in which the policies were applied

§ Which policies were applied

§ Which policies were filtered out

§ Group membership

You can use the switches shown in Table 7.3 to get information for remote users and computers and to enable other options.

TABLE 7.3 gpresult switches

Switch

Description

/S systemname

Generates RSoP information for a remote computer name.

/USER username

Generates RSoP information for a remote username.

/x /h filename

Generates a report in either XML (/x) or HTML (/h) format. The filename and location is specified by the filename parameter.

/V

Specifies verbose mode, which displays more verbose information such as user rights information.

/Z

Specifies an even greater level of verbose information.

/SCOPE MACHINE

Displays maximum information about the computer policies applied to this system.

/SCOPE USER

Displays maximum information about the user policies applied to this system.

>textfile.txt

Writes the output to a text file.

image Table 7.3 is not a complete list. To see a complete list of the gpresult.exe switches, visit Microsoft at www.microsoft.com.

For example, to obtain information about user wpanek in a system called STELLACON, you would use the command gpresult/S STELLACON/USERwpanek.

Through the use of these techniques, you should be able to track down even the most elusive Group Policy problems. Remember, however, that good troubleshooting skills do not replace planning adequately and maintaining GPO settings!

Summary

In this chapter, you examined Active Directory’s solution to a common headache for many systems administrators: policy settings. Specifically, I discussed topics that covered Group Policy.

I covered the fundamentals of Group Policy, including its fundamental purpose. You can use Group Policy to enforce granular permissions for users in an Active Directory environment. Group policies can restrict and modify the actions allowed for users and computers within the Active Directory environment.

Certain Group Policy settings may apply to users, computers, or both. Computer settings affect all users who access the machines to which the policy applies. User settings affect users regardless of the machines to which they log on.

You learned that you can link Group Policy objects to Active Directory sites, domains, or OUs. This link determines to which objects the policies apply. GPO links can interact through inheritance and filtering to result in an effective set of policies.

The chapter covered inheritance and how GPOs filter down. I showed you how to use the Enforced option on a GPO issued from a parent and how to block a GPO from a child.

You can also use administrative templates to simplify the creation of GPOs. There are some basic default templates that come with Windows Server 2012 R2.

In addition, administrators can delegate control over GPOs in order to distribute administrative responsibilities. Delegation is an important concept because it allows for distributed administration.

You can also deploy software using GPOs. This feature can save time and increase productivity throughout the entire software management life cycle by automating software installation and removal on client computers. The Windows Installer offers a more robust method for managing installation and removal, and applications that support it can take advantage of new Active Directory features. Make sure you are comfortable using the Windows Installer.

You learned about publishing applications via Active Directory and the difference between publishing and assigning applications. You can assign some applications to users and computers so that they are always available. You can also publish them to users so that the user can install them with minimal effort when required.

You also learned how to prepare for software deployment. Before your users can take advantage of automated software installation, you must set up an installation share and provide the appropriate permissions.

The final portion of the chapter covered the Resultant Set of Policy (RSoP) tool, which you can use in logging mode or planning mode to determine exactly which set of policies apply to users, computers, OUs, domains, and sites.

Exam Essentials

Understand the purpose of Group Policy. System administrators use Group Policy to enforce granular permissions for users in an Active Directory environment.

Understand user and computer settings. Certain Group Policy settings may apply to users, computers, or both. Computer settings affect all users who access the machines to which the policy applies. User settings affect users, regardless of the machines to which they log on.

Know the interactions between Group Policy objects and Active Directory. GPOs can be linked to Active Directory objects. This link determines to which objects the policies apply.

Understand filtering and inheritance interactions between GPOs. For ease of administration, GPOs can interact via inheritance and filtering. It is important to understand these interactions when you are implementing and troubleshooting Group Policy.

Know how Group Policy settings can affect script policies and network settings. You can use special sets of GPOs to manage network configuration settings.

Understand how delegation of administration can be used in an Active Directory environment. Delegation is an important concept because it allows for distributed administration.

Know how to use the Resultant Set of Policy (RSoP) tool to troubleshoot and plan Group Policy. Windows Server 2012 R2 includes the RSoP feature, which you can run in logging mode or planning mode to determine exactly which set of policies applies to users, computers, OUs, domains, and sites.

Identify common problems with the software life cycle. IT professionals face many challenges with client applications, including development, deployment, maintenance, and troubleshooting.

Understand the benefits of the Windows Installer. Using the Windows Installer is an updated way to install applications on Windows-based machines. It offers a more robust method for making the system changes required by applications, and it allows for a cleaner uninstall. Windows Installer–based applications can also take advantage of new Active Directory features.

Understand the difference between publishing and assigning applications. Some applications can be assigned to users and computers so that they are always available. Applications can be published to users so that the user may install the application with a minimal amount of effort when it is required.

Know how to prepare for software deployment. Before your users can take advantage of automated software installation, you must set up an installation share and provide the appropriate permissions.

Know how to configure application settings using Active Directory and Group Policy. Using standard Windows Server 2012 R2 administrative tools, you can create an application policy that meets your requirements. You can use automatic, on-demand installation of applications as well as many other features.

Create application categories to simplify the list of published applications. It’s important to group applications by functionality or the users to whom they apply, especially in organizations that support a large number of programs.

Review Questions

1. The process of assigning permissions to set Group Policy for objects within an OU is known as:

A. Promotion

B. Inheritance

C. Delegation

D. Filtering

2. Which of the following statements is true regarding the actions that occur when a software package is removed from a GPO that is linked to an OU?

A. The application will be automatically uninstalled for all users within the OU.

B. Current application installations will be unaffected by the change.

C. The system administrator may determine the effect.

D. The current user may determine the effect.

3. You are the network administrator for your organization. You are working on creating a new GPO for the sales OU. You want the GPO to take effect immediately. Which command would you use?

A. GPForce

B. GPUpdate

C. GPResult

D. GPExecute

4. You are the network administrator for your organization. You are working on creating a new GPO for the Marketing OU. You want the GPO to take effect immediately, and you need to use Windows PowerShell. Which PowerShell cmdlet command would you use?

A. Invoke-GPUpdate

B. Invoke-GPForce

C. Invoke-GPResult

D. Invoke-GPExecute

5. You are the network administrator, and you have decided to set up a GPO with item-level targeting. Which of the following is not an option for item-level targeting?

A. Battery Present Targeting

B. Computer Name Targeting

C. CPU Speed Targeting

D. DVD Present Targeting

6. You are the network administrator for a large organization that uses Windows Server 2012 R2 domain controllers and DNS servers. All of your client machines currently have the Windows XP operating system. You want to be able to have client computers edit the domain-based GPOs by using the ADMX files that are located in the ADMX Central Store. How do you accomplish this task? (Choose all that apply.)

A. Upgrade your clients to Windows 8.

B. Upgrade your clients to Windows 7.

C. Add the client machines to the ADMX edit utility.

D. In the ADMX store, choose the box Allow All Client Privileges.

7. You work for an organization with a single Windows Server 2012 R2 Active Directory domain. The domain has OUs for Sales, Marketing, Admin, R&D, and Finance. You need the users in the Finance OU only to get Microsoft Office 2010 installed automatically onto their computers. You create a GPO named OfficeApp. What is the next step in getting all of the Finance users Office 2010?

A. Edit the GPO, and assign the Office application to the user’s account. Link the GPO to the Finance OU.

B. Edit the GPO, and assign the Office application to the user’s account. Link the GPO to the domain.

C. Edit the GPO, and assign the Office application to the computer account. Link the GPO to the domain.

D. Edit the GPO, and assign the Office application to the computer account. Link the GPO to the Finance OU.

8. You are hired as a consultant to the ABC Company. The owner of the company complains that she continues to have desktop wallpaper that she did not choose. When you speak with the IT team, you find out that a former employee created 20 GPOs and they have not been able to figure out which GPO is changing the owner’s desktop wallpaper. How can you resolve this issue?

A. Run the RSoP utility against all forest computer accounts.

B. Run the RSoP utility against the owner’s computer account.

C. Run the RSoP utility against the owner’s user account.

D. Run the RSoP utility against all domain computer accounts.

9. You are the network administrator for a large organization that has multiple sites and multiple OUs. You have a site named SalesSite that is for the sales building across the street. In the domain, there is an OU for all salespeople called Sales. You set up a GPO for the SalesSite, and you need to be sure that it applies to the Sales OU. The Sales OU GPOs cannot override the SalesSite GPO. What do you do?

A. On the GPO, disable the Block Child Inheritance setting.

B. On the GPO, set the Enforce setting.

C. On the GPO, set the priorities to 1.

D. On the Sales OU, set the Inherit Parent Policy settings.

10. You are the administrator for an organization that has multiple locations. You are running Windows Server 2012 R2, and you have only one domain with multiple OUs set up for each location. One of your locations, Boston, is connected to the main location by a 256Kbps ISDN line. You configure a GPO to assign a sales application to all computers in the entire domain. You have to be sure that Boston users receive the GPO properly. What should you do?

A. Disable the Slow Link Detection setting in the GPO.

B. Link the GPO to the Boston OU.

C. Change the properties of the GPO to publish the application to the Boston OU.

D. Have the users in Boston run the GPResult/force command.