6.4. Domain Group PolicyDomain-based GPs offer a much more flexible and configurable set of standards and settings for your organization than local GPs. In this section, I'll discuss the four most common methods of managing your IT assets centrally using domain GP: configuring a security standard, installing software using the IntelliMirror technology found in Windows Server 2003, redirecting folders present in the user interface to network locations, and writing and launching scripts triggered by events such as logons and logoffs. 6.4.1. Security SettingsAs discussed earlier, one of the most useful aspects of GP is its ability to control security settings and configuration from a central location within the organization. Security policy is composed of three key components: restricted groups , registry settings, and filesystem settings. In this section, I'll take a look at each of them. 6.4.1.1. Restricted groupsThe restricted groups option allows you to modify the current group configuration and membership on your client computers. When this policy is applied to workstations and servers, their individual group configurations are modified to match that configured inside the policy. The policy contains members and members of lists that overwrite any configuration on the target computers. For example, if you were to add the Administrator group to the policy but not add any users to the members of this group list, and then you applied the policy, Windows would remove any users currently in those groups on the client computers. However, the other facet of the policy, groups of which the added group is currently a member, is only additive: if the list is empty, no modifications are made to the client computers. Only additions are processed and changed. Only the groups listed inside the Details window of the Restricted Groups policy branch can be modified using the policy, but it's a great way to keep individual users from modifying powerful groups on their own systems. To modify the restricted groups policy, do the following:
Figure 6-24. The Restricted Groups list screen6.4.1.2. File system and registry policyYou also can use GPs to configure permissions on filesystem objects and registry keys. You can set entries on the ACLs of individual files, folders, and registry keys from a central location. If you make this change at the domain-wide levelone of the few changes I recommend and endorse at that levelregistries are protected against meddling users all over the enterprise, which is definitely a benefit. To add a registry key to be protected to a GPO, follow these steps:
Figure 6-25. The Registry Key ACL editor screenTo add a file or folder to be protected to a GPO, follow these steps:
Once you've selected the objects in question, you'll be prompted for their permissions just like I discussed in Chapter 3. After you enter the appropriate permissions, you'll be prompted to configure the properties of inheritance for these new permissions. This is shown in Figure 6-27. If you select the configure option, you also will need to select how permissions are applied. If you choose to apply inheritable security to this file or folder and to its subfolders, the new permissions are applied to all child objects that do not have a permission or ACL entry explicitly set. This preserves your custom permissions on a tree but also automatically overwrites permissions simply inherited by default. If you choose to replace existing security for this file or folder and its subfolders, you overwrite all permissions on any child folders, including those permissions explicitly set. If you'd rather not have any of these methods used to apply permissions, simply choose the following option: Prevent the application of security policies to this file or folder and its subfolders. Doing so will make child files and folders immune to the permissions assigned by this new policy. Figure 6-26. The File System ACL editor screenFigure 6-27. Configuring inheritance on protected filesystem or registry objects6.4.2. IntelliMirror: Software InstallationIn my opinion, software installation is one of the coolest and most useful features of GP, and I know many administrators who agree with me. Using Microsoft's IntelliMirror technology introduced in Windows 2000, administrators using GP can distribute software applications initially, using a push or pull method, and then upgrade, redeploy, or remove that software either wholesale or when certain conditions apply. IntelliMirror also offers intelligent application repair features so that when critical files for an application deployed through IntelliMirror are corrupted or deleted, Windows takes over and fixes the problem so that the application will still start and function correctly. This is a big timesaver. You can distribute and install applications in your organization in two ways. You can assign a software package, which places a shortcut on the user's Start menu and loads the advertisement for the package into the computer's registry. Or you can publish an application, which simply places the program with the Add/Remove Programs applet in the Control Panel. The user can elect to install the software at his discretion and at a convenient time. You also can distribute applications via the assign and publish functionality to a computer or a user. If you assign a package to a user, the application is installed on the local system the first time the user runs the software. Incidentally, you can also elect to install such an application when the user logs on, although this can make for long boot times and calls to the help desk. These user-assigned applications follow a user around the network to each computer to ensure that he has all the applications he should on each computer. If you assign a package to a computer, the application is installed on that system when booted up, and the software is installed only on the computer defined in the policy. Applications don't necessarily follow a user around. If you use the publish functionality of IntelliMirror, you can publish to only a specific user because computers can't choose how and where to install software. Published applications also are not quite as robust as assigned applications and the repair functionality of published applications is limited.
6.4.2.1. Packaging softwareThe easiest way to publish and assign software is through the use of Microsoft Installer packages, or MSI files. Applications packaged in Installer format include a database of changes to make to files and registry keys, instructions on removing previous or outdated version of software, and strategies to install on multiple versions of Windows within one file. MSI files also allow intelligent repair functionality for use if installations become corrupted on individual computers, and their rollback function for removing or redeploying an application is useful as well. IntelliMirror and GP-based software distribution are designed to work with applications that install using an MSI package. But all is not lost if your software isn't offered in MSI format. First, you can use the ZAP file method. You can use a .ZAP file when software isn't available with an MSI package to publish (but not assign) the application. A ZAP file is nothing more than a description of an application, its setup program, and any associated file extensions. A sample ZAP file for Adobe's Acrobat Reader 5.0 is shown here: Line 1: [Application] Line 2: FriendlyName = Adobe Acrobat Reader 5.0 Line 3: SetupCommand = \\deploy\adobe\rp505enu.exe Line 4: DisplayVersion = 5.0 Line 5: Publisher = Adobe Corporation Line 6: URL = http://www.adobe.com Line 7: Line 8: [Ext] Line 9: PDF= A few notes about this ZAP file: the FriendlyName section shows the application name, which will appear in the Add/Remove Programs applet within the Control Panel on the computers to which the package is published. It also contains the Setup directive, which tells Windows the network path of the file to install the package. The other tags, although offering more information on the version, manufacturer, and Internet address of the manufacturer, are optional. The Ext section lists file extensions to be associated with the program, each followed by an equals sign. The ZAP file method has a few caveats. First and foremost, because ZAP file installations can only be published, you lose the robustness and intelligent repair features of software applications assigned to computers and users. You also can't set an application deployed via a ZAP file to install automatically on first use, and you can't upgrade or remove an application deployed via a ZAP file using a GPO. In addition, a specific user must have appropriate permissions to run the package's installer executable and to access the source files for the installation. And, the installation probably is not very automated, so the process likely would require user intervention to answer prompts such as the destination directory, installation options, and so forth, which is something we all try to avoid when possible. Finally, because the installer isn't granted sweeping administrative privileges during the setup process like an MSI installer is, you might have conflicts and problems to troubleshoot with a mass package deployment.
If the ZAP file method doesn't appeal to you, you can use a repacking tool, such as Veritas WinInstall LE or the InstallShield deployment tools. These tools will take a snapshot of your current system configuration and prompt you to install the software you want to package. Once the installation is complete, these tools will take another snapshot, record what changed on the filesystem and registry, and prompt you with a list of what it detected. You go through the list, make sure the changes listed were due to installing the software and not to errant behavior on the part of Windows, and then confirm the list. The software will create an MSI with the program's installer and a database of filesystem and registry changes. Using this method, you gain the robustness and rollback features of using an MSI installer as opposed to ZAP files. However, the repackaging tools can tend to be a bit flaky, and sometimes you'll have difficulty installing them on multiple platforms. There's not a good way around that, other than obtaining an MSI directly from the software vendor, but it's somewhat of a middle ground between the inflexible ZAP files and a true MSI from the manufacturer.
6.4.2.2. An example deploymentIn this section, I'll step through an actual software deployment using GP, publishing an application for a user:
Of course, to assign an application to a user, you can simply follow the preceding steps and select Assign instead of Publish in step 6. To assign an application to a computer, use the same process, but use Computer Configuration instead of User Configuration in step 3 and select Assign instead of Publish in step 6. 6.4.2.3. Deployment propertiesYou'll probably want to fine-tune the settings for deployment, and you can do this through the properties box for the software. Right-click the name of the software package inside the Group Policy Object Editor and then select Properties. The policy properties box contains the following six tabs.
Remember the following security settings guidelines when deploying software via security group filtering:
Look back earlier in the chapter to the section "The Scope of Group Policy Objects" for a refresher on this. You also can determine the order in which applications will be installed for a given file extension, a useful feature if your organization associates one file extension with multiple software packages. To do so, right-click the Software Installation node within the Group Policy Object Editor (in the lefthand pane) and select Properties. From there, navigate to the File Extensions tab. Select an extension from the drop-down list box, and then adjust the priority, from highest to lowest, of each application in the list box using the Up and Down buttons. If only one application in GP is associated with an extension, this feature will be grayed out because no priority needs to be established. You also can configure other deployment options on this property sheet using the following tabs:
6.4.2.4. Redeploying and removing softwareIf you need to patch an existing software deployment that uses an MSI file, you can take advantage of the redeployment functionality of IntelliMirror. Simply copy the new MSI and associated files over the existing copies on the network share. Then, inside the GPO that contains the deployment configuration for the existing package, right-click the package in the details window inside the Group Policy Object Editor and select Redeploy from the All Tasks menu. Click the Yes button to confirm your choice. The first time the application is started on client computers, regardless of whether the package was assigned or published, the new MSI will be installed. Along the same lines, if you need to remove installed software, you can right-click the package inside the Group Policy Object Editor and select Remove from the All Tasks menu. You'll be presented with the window shown in Figure 6-34. Figure 6-34. The Remove Software dialog boxYou can choose to either forcibly remove the software immediately, which will uninstall the application no matter what, or simply remove the software from the list of available software, which will allow current installations to continue to use the software, but will prevent new computers from obtaining the software through GP. 6.4.2.5. Deploying service packs using GPYou also can distribute service packs for Windows 2000, XP, and Windows Server 2003 through the IntelliMirror software installation features of GPOs. Doing so can go a long way toward eliminating a tedious and time-consuming administrative task. You can assign the service pack to computers for mandatory deployment, or you can publish the service pack to a user so that he can choose to install it if his situation warrants it. If you are assigning the service pack to computers, you simply can point a GPO to the UPDATE.MSI file included in the extracted portion of all current service packs from Microsoft. However, if you're publishing the service pack, you'll need to create a ZAP file and then point the software installation GPO to that ZAP file. Again, you can't publish MSI files. To deploy a service pack using IntelliMirror, follow these steps:
The policy is set and the service pack will either be assigned or published, depending on your choices. Keep in mind that service packs are typically large files, so you should deploy them after considering the effect that process would have on both your network bandwidth and the time it would take to install locally on the client machines. Additionally, I would avoid automatically deploying service packs on your domain controllers. These machines are sensitive beasts that hold the keys to your Active Directorymanually install service packs on these machines one by one and test them to make sure there are no ill effects.
6.4.3. IntelliMirror: Folder RedirectionYou can use the folder redirection functionality of GP to change the target location of many folders within a particular user's Windows interface. For example, you can specify custom locations for the Application Data, Desktop, My Documents (including the My Pictures subfolder), and Start Menu folders. Using folder redirection circumvents the nasty problem of roaming profiles: severe network traffic hikes caused by copying large My Documents and Desktop folders to workstations around the network when users log on. You also can back up the share where the folders are redirected using a normal network backup procedure, automatically protecting the contents. To access the folder redirection functionality, launch the Group Policy Object Editor for a particular GPO and navigate through User Configuration, Windows Settings, and Folder Redirection. In the righthand pane you'll see the four folders you can redirect. Right-click each folder to bring up the Properties window. Figure 6-35 shows this screen. On the Target tab, you can choose the type of redirection for this policy. For this example, choose the basic method, which simply redirects all users' folders to the same location. Next, enter the target folder at the bottom of the screen under Root Path, and select the option to create a new folder for each user underneath the root path. Then, move to the Settings tab, and choose the following settings.
6.4.3.1. Redirecting folders based on group membershipIf you want to redirect some profile folders to different locations based on the different groups to which a user belongs, you can use the Advanced method of redirection inside the redirect policy properties page, on the Target tab. When you select Advanced from the drop-down setting box indicating the type of redirection, click the Add button. The Specify Group and Location box will appear, as shown in Figure 6-36. Figure 6-36. Redirecting folders based on group membershipEnter the name of a security group, and then enter the network path to the folders. Always use a UNC path, even if the folders are local to your machine, so that users taking advantage of roaming profiles will see the correct folders in an absolute path and not wrongly translate a local, relative path. Click OK when you're done, and then repeat the process for as many groups as you need. If your users are creatures of habit, you even can turn on the Offline Files and Folders feature on the share where you've stored the redirected folders. This way, Windows will continue to display and use a customized environment even when the network is down and the share can't be reached. 6.4.3.2. Removing a redirection policyIt can be a bit difficult to track what happens to redirected folders if you decide to remove a redirection policy. It really depends on the appropriate setting on the Settings tab of the redirected folder's policy properties sheet. If you've selected to redirect the folder back to the local user profile when the policy is removed, and the option to move the contents of the local folder to a new location is enabled, the folder will return to its original location and the contents of the folder will be copied back to the original location but not deleted from the redirected location. If the option to move the contents of the folder to a new location is disabled, the folder will revert to its original location, but the contents of the folder will not be copied or moved to the original location. This means the user is unable to access the contents of the redirected folder from the special folder's UI within the shell, but using a UNC path, she still can access the redirected folder and retrieve its contents manually. If you've selected to leave the folder in the new location when the policy is removed, the folder and its contents will remain at the redirected location, and the user will have access to it, regardless of whether the option to move the contents of the folder to the new location is enabled or disabled.
6.4.4. Software Restriction PoliciesNew to Windows Server 2003 are software restriction policies , which allow you to control the execution of certain programs. It's an excellent feature to use on terminal servers or machines serving as a public kiosk, so users are locked into one specific function and can't mess with administrative tools or Internet applications and utilities. Windows can identify software to either restrict or allow in several different ways. For one, it can use hash rules, which are made by identifying characteristics of files and executables that come with a program and generating an algorithmic hash from them. Hashes are great for identifying specific versions of programs because the hash value would change when different files are used to compute the hash (which is a near certainty with newer version of a program). Certificate rules can identify software via a digital signature, which is a useful method to secure authorized scripts. Windows also can identify software via its path and the Internet zone (inside Internet Explorer) from which a particular piece of software is downloaded. Finally, Windows can create a rule that catches any software not explicitly identified either in a list or by any other rule. (Control for programs executed within a browser is lacking from the GP standpoint, but improvements to Internet Explorer in Windows XP Service Pack 2 pick up a bit of this slack.) Windows matches programs to rules in the order in which they're listed in the software restriction GPO, and if more than one rule identifies the same program, the rule that catches the program most specifically will trump any other rule. You might be tempted to create a rule that disallows programs from running by default aside from those explicitly placed in an exception list. This seems like an easy way out, but it really can lobotomize a system unless you take great care to create an exception for every Windows executable a user might need, including his application programs. It can also step on the toes of any user logon scripts that might be necessary to create a secure environment. If you decide to go this route, it's imperative that you extensively test any restriction policies and exception lists in a lab. Also, when you do create the actual software restriction GPO, make sure to add the Domain Administrators group to the GPO's ACL and explicitly deny the Apply Group Policy permission to the GPOthis will enable an administrator to reverse the policy and not lock himself out. Once you're ready to create the policy, follow this procedure:
6.4.5. ScriptsUsing GP , you can assign scripts to entire domains, organizational units, sites, and groups instead of repeatedly entering the same login script into multiple users' profiles. You can launch four types of scripts using a GPO: logon and logoff scripts, which apply to users, and startup and shutdown scripts, which apply to computers. Startup scripts are executed before logon scripts, and logoff scripts are executed before shutdown scripts. You can write scripts in any number of languages. Windows Server 2003 is prepared to accept Jscript (.JS) and Visual Basic Scripting Edition (.VBS) files in addition to batch (.BAT), compiled command scripts (.COM), and application executables (.EXE). Scripts to be run through GP are stored on domain controllers in:
with yourdomain.com replaced with your fully qualified domain name. You can assign startup and shutdown scripts in GP using the following procedure:
You can assign logon and logoff scripts in GP using the following procedure:
You can further define properties for these scripts under the Computer Configuration/Administrative Templates and User Configuration/Administrative Templates/System/Scripts nodes in the Group Policy Object Editor. For users running scripts, you have the following options (see Figure 6-37):
For computers running scripts, you can configure the following options (see Figure 6-38):
Figure 6-37. Logon and logoff script optionsFigure 6-38. Script options |