Group Policy Objects phần 3

Chia sẻ: Nghia Tuan | Ngày: | Loại File: PDF | Số trang:6

Thêm vào BST

Báo xấu

133
lượt xem 14
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

1. The Group Policy Object Editor will launch, and it will be focused on the selected GPO. Under the GPO name, you see two nodes: Computer Configuration and User Configuration

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Group Policy Objects phần 3

1. The Group Policy Object Editor will launch, and it will be focused on the selected GPO. Under the GPO name, you see two nodes: Computer Configuration and User Configuration. To demonstrate administrative templates, let's focus on the User Settings. Expand the User Configuration node, then expand the Administrative Templates node. You'll see a tree of folders representing the available areas for administrative template controls (Fig. 11.13). Figure 11.13: The Group Policy Object Editor focused on the Default Domain Policy 2. What you see is a graphical representation of the ADM files that are loaded by this particular GPO. The ADM files dictate which folders, registry keys, and values are presented here. Each folder, such as Control Panel, Network, and System, represents ADM categories. Within each category are sets of policies that you can specify. For example, if you expand the System folder, you will see a subfolder named Power Management. After you expand a specific subfolder, the right pane of the Group Policy Object Editor window will expose the list of all available registry limitations that can be set in relation to the selected feature. For example, the Power Management folder contains the Prompt for password on resume from hibernate / suspend policy. (When you configure this policy, the appropriate setting will be created or modified in registry.) 3. To configure a specific policy, simply double-click it to open the respective Properties window (Fig. 11.14). Previously in this section, when discussing the ADM file structure, I pointed out the new keywords appearing with each new Windows version. Now, notice the effect they have on the GPO Editor user interface. For example, the EXPLAIN keyword appears in the Properties window's Explain tab, which you can click to read Help text associated with the selected policy item. Also notice the Supported on: At least Windows XP Professional… string at the bottom of this dialog. It appeared because the SUPPORTED statement was included in the ADM file. Despite these changes to the GPO Editor user interface, the template offers familiar choices. For example, like in Windows NT 4.0 policies, policy items in Windows 2000, Windows XP, or Windows Server 2003 can have three different states (Fig. 11.14), as follows:
o Not Configured — The particular registry value behind this policy item is not changed, regardless of its state. o Disabled — This particular policy item is disabled. That is, if the policy is Prompt for password on resume from hibernate / suspend — when it is disabled, each user can decide whether to automatically lock his or her computer after performing a resume operation. o Enabled — This policy item is enforced at all times. Figure 11.14: Policy items in Windows 2000, Windows XP or Windows Server 2003 can have one of three states: Not Configured, Enabled, or Disabled 4. If multiple GPOs are applied to a user or machine, two identical policy items from different GPOs could contradict each other (i.e., one enables an item and the other disables it). In this case, it's the "last-writer-wins" approach that resolves the conflict. The last writer may not always be obvious because GPOs can reside at the site, domain, or OU levels, and each of level can have multiple GPOs. I already mentioned the order of precedence in the Directory (Local, Site, Domain, OU). In addition, a set of up/down buttons next to the list of available GPOs allows the order of precedence to be set within a container. The higher a GPO is in the list, the later it is processed. Later settings override previous ones. Once you set all of the policy items within a GPO, where is this information kept? As previously mentioned, it is replicated in the SYSVOL directory in the Group Policy Template for that GPO. Both machine- and user-based administrative template settings
are stored in a file called Registry.pol. However, each is stored in its own folder. For example, user-specific Registry.pol is located in %SystemRoot%\sysvol\ domain\policies\\User. Registry.pol replaces the Ntconfig.pol and Config.pol files, which were used in Windows versions earlier than Windows 2000. However, unlike Ntconfig.pol, Registry.pol is not a valid registry hive file. You can't load it into a temporary hive, nor can you view it. It is a text file, but it contains non-printable characters and cannot be edited using a text editor, such as Notepad. However, one drawback of Windows NT 4.0 policies was the effect of tattooing. When you remove a policy from the domain, the entries are left in the registry for the affected user or machine. This is not the case in Windows 2000 and later. In these newer versions, if you disable or remove a GPO that has made registry changes, the corresponding changes are also removed from the registry. In Windows NT 4.0, the default path for policy restrictions was in HKCU or HKLM, under the Software\MS\Windows\CurrentVersion\Policies keys. (See the full path previously given in this section.) Starting with Windows 2000, the default path for policy settings has been changed to HKCU and HKLM under the Software\Policies key. As long as your ADM templates make changes to either of these policy keys, any tattooing is cleaned up when you remove a GPO. Of course, you are not limited to these keys. You could easily create an ADM file that enforces registry policy on HKLM\Software\Myapp. However, if a custom ADM file has been created that strays from the well-known keys, those custom keys won't be cleaned up when the GPO is removed. How Software Installation Works Another important GPO feature that directly affects the system registry is Software Installation. Any application carrying the label "Designed for Windows" must use registry. Any time a setup program runs, it reads the registry information to determine if all the components necessary to complete the installation procedure successfully are present in the system. It then adds new configuration data to the registry. For this reason, Setup programs — including Windows Setup and setup utilities that install third-party software and/or device drivers — always hold the first position in the list of components using the system registry. At this point, we come to an important issue. Software installation and distribution technology has undergone significant advances in recent years. Before proceeding with a discussion of these technological improvements, ask yourself a simple question: How are you installing software today? If you're still running from machine to machine with the CD-ROM media and forcing users to take a coffee break for 30 to 60 minutes while you install and test the required application, your method may be inefficient. For a home office or small network (about 10 machines), this may be acceptable. When the number of computers, users, and applications increases, this method quickly becomes a "poor
administrative experience". Massive deployments today involve thousands of computers, most of which are administrated remotely. Therefore, it was necessary to develop management software that can remotely deliver most standard software packages to a client. Understanding this, Microsoft introduced the Software Installation feature, a tool that enables software distribution and desktop configuration management via Active Directory. Using this feature, you can present the required applications for installation to users or machines within specific domain, site, or OU by adding that application to a GPO in Active Directory. The effect of this action is that users subject to that GPO have the required applications installed for them. Of course, the installation does not happen all at once; this would render the machine useless under the weight of simultaneous application installations. Rather, the applications are installed in a "just-in-time" fashion, depending on the configuration within the GPO. The Windows Server 2003 family includes several improved technologies and features that significantly ease the task of OS and add-on software deployment: Remote Installation Services (RIS). Administrators can use RIS servers to deploy all editions of Windows 2000, Windows XP Professional, and Windows Server 2003 (except Windows 2000 Datacenter Server and Windows Server 2003, Datacenter Edition.) Automated deployment is enhanced with tighter security, improved performance to major components in RIS — such as Trivial File Transfer Protocol (TFTP) — and Hardware Abstraction Layer (HAL) filtering to ensure that images are recognized only by machines with a compatible HAL. User State Migration. Migrating files and settings for multiple users in a corporate environment is easier with the User State Migration Tool (USMT). USMT gives administrators command-line capabilities when they customize specific settings or make unique modifications to Registry. In addition, Windows Server 2003 includes a Files and Settings Transfer Wizard designed for individuals or small- office users. The wizard is also useful in a corporate network environment for employees who receive a new computer and need to migrate their own files and settings without the support of an IT department or help desk. Windows Installer. Managing software applications in a corporate environment has traditionally burdened organizations with high costs. With Windows Installer, administrators can greatly simplify the process of customizing installations, updating and upgrading applications, and resolving configuration problems. Windows Installer can also manage shared resources, enforce consistent file version rules, and diagnose and repair applications at run time. To deliver an application to users or machines, you normally use the Group Policy Object Editor MMC snap-in focused on the desired GPO. When you are ready to deliver a specific application to users:
1. Place the installation package on the network share. Make sure that it is accessible to the clients. 2. Start the Active Directory Users and Computers MMC snap-in, right-click the name of the domain or OU of interest, and select the Properties command from the context menu. Then go to the Group Policy tab, highlight the required GPO, and click the Edit button. 3. The Group Policy Object Editor will launch, and it will be focused on the selected GPO. Expand the console tree and locate the Software installation nodes both under Computer Configuration | Software Settings and User Configuration | Software Settings (Fig. 11.15). The Software Installation feature allows you to deliver applications to computers and users. For example, you can make applications A and B available to computers within a given domain and make applications C and D available to users within that domain. The effect of this setup will be as follows: Applications A and B will be installed for all users who work on computers subject to that GPO. Additionally, applications C and D will be installed for all users subject to that GPO who logon at the same machine. The example presented in Fig. 11.15 shows several applications published for domain users. Figure 11.15: Publishing several applications using the Group Policy Editor MMC snap-in 4. Right-click the Software installation node under Computer Configuration | Software Settings or User Configuration | Software Settings, depending on whether you want to make the application available to computers or users within a given domain or OU. From the right-click menu, select New | Package commands. You will be prompted to specify the network path to the application's distribution package. Note The Software Installation feature supports a new package setup format called
the Windows Installer. (Windows Installer technology will be covered in more detail later in this chapter.) Application setups packaged using the Windows Installer have an MSI filename extension. The Software Installation feature also supports a down-level format, known as Zero Administration Packaging (ZAP). ZAP files are simple text INI files that let you publish (not assign) your existing application setups without having to convert them to the MSI format. 5. After you specify the network path to the distribution sharepoint, the Deploy Software window will appear (Fig. 11.16). You will be prompted to select the deployment method. You can either publish or assign the application that you are going to deploy. The difference between these two methods lies in how an application presents itself to the user's desktop and how it uses the registry to enable just-in-time installation. When you publish an application, you make it available for your users if they need it. This means it will be an "optional" application available to the user via the Control Panel's Add/Remove Programs applet (Fig. 11.17). Conversely, when you assign an application, you take the first step toward installing that application for a user or machine. An application will be "advertised" in the user's environment and Windows Explorer shell. An icon for that application will be placed to the user's Start menu or Desktop, and filename extension association for that application will be created in the registry under HKEY_CLASSES_ROOT. Figure 11.16: The Deploy Software dialog prompts you to choose whether you are going to publish or assign the selected application