• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    Managing Individual Group Policy Types

    Now that we've seen how servers dole out the various group policies and how clients download and apply them, let's look at specific policy types to see how to use them to our advantage.

    This topic covers the mechanics of implementing and troubleshooting the various policy types. For further information, refer to the following:

    • Chapter 19, "Managing the User Operating Environment," has more information about using folder redirection and logon scripts to control the user environment.

    • Chapter 11, "Understanding Network Access Security and Kerberos," covers specifics about using security policies.

    • Chapter 17, "Managing File Encryption," and Chapter 18, "Managing a Public Key Infrastructure," cover specifics about EFS, PKI, and IPSec policies.

    • Chapter 2, "Performing Upgrades and Automated Installations," covers how to use RIS policies to control the Client Installation Wizard.

    Internet Explorer Maintenance policies fall outside the scope of this book.

    Security Policies

    The earlier part of this chapter covered the specifics of deploying security-related group policies in a domain. This section shows how the deployment mechanism works and how to configure security without the help of group policies.

    Windows Server 2003, Windows XP, and Windows 2000 computers store their security settings in a local database called Secedit.sdb. This database is located in \Windows\Security\Database. Security-based group policies work by applying security settings to the Secedit.sdb database.

    In addition to Secedit.sdb entries, security policies can also change the permission settings for NTFS files and folders, Registry keys, and local services.

    Security-Related GPT Files

    When you create security-related policy settings in a GPO using the Group Policy Editor, the GPE saves the settings to a GPT file called GptTmpl.inf.

    Clients that are affected by the GPO download the GptTmpl.inf file and copy it to a local folder called \Windows\Security\Templates\Policy. If the client is affected by multiple GPOs that have security policy settings, it copies each GptTmpl.inf in sequence and gives them sequence numbers with an .inf extension. The sequence number matches the preference hierarchy of the GPO. The only exception is the Default Domain Policy, which is given a special .dom extension.

    When a user logs on, the Winlogon process takes the contents of the .dom and .inf files and applies them to the local machine's security database and Registry. You can see the results of this transaction in the Winlogon.log file under \Windows\Security\Log. Security policies take effect immediately when they are downloaded.

    Local clients also download security policy changes as part of their normal background refresh. The refresh occurs every 90 to 120 minutes for member computers and every 5 minutes for domain controllers. An additional background refresh of security settings only occurs every 16 hours. The standard background refresh only downloads policies that have changed. The 16-hour refresh downloads all security policies regardless of whether or not they have changed.

    Special Handling for Account Policies

    Account policies such as password policies, account lockout policies, and Kerberos policies can only be set in the Default Domain GPO. The policies appear in other GPOs, but setting them has no effect.

    To view the security policies applied to a local server, launch the Local Security Settings console via Start | Programs | Administrative Tools | Local Security Policy. (Domain controllers have Domain Controller Security Policy and Domain Security Policy selections.) Figure 12.18 shows an example of the local security policies for a domain member server.

    Figure 12.18. Local Security Settings console for a domain member server.


    As you drill down through the policy settings, you'll notice that some have icons with little blue markings and some have icons that look like two little servers with a scroll of paper. The second icon type indicates that the policy settings originated in a group policy. The first icon type indicates that the policy originated in the local security database.

    Default Security Templates

    For domain controllers and domain member computers, group policies are the ideal way to manage security settings. However, you can also change security settings directly using the Secedit utility. Secedit relies on a template file to provide the settings that it applies to the Secedit.sdb database and other security objects.

    There are two sets of security templates. The first are stored in \Windows\INF. The system uses these templates to do wholesales changes in security when a server changes its operating character. Here are the templates and their purposes:

    • DEFLTSV.INF. Applied when a server is installed from scratch.

    • DEFLTDC.INF. Applied when a server is promoted to a domain controller.

    • DSUP.INF. Applied when a server is upgraded from Windows 2000 or NT4.

    • DCUP5.INF. Applied when a domain controller is upgraded from a Windows 2000 domain controller.

    • DSUPT.INF. Applied when a server is upgraded from NT4 Terminal Server Edition or a Windows 2000 server that was running in Application mode.

    • DCFIRST.INF. Applied to the first server promoted to a domain controller in a domain. This template contains special Kerberos policies, account policies, restricted groups, and group membership.

    Specialty Security Templates

    In addition to the security templates applied during Setup and domain controller promotion, there are additional security templates stored under \Windows\Security\ Templates. These templates contain prepackaged settings for basic, secure, and high security configurations for servers, workstations, and domain controllers. There is also a package for removing the Terminal Server User group from the NTFS permissions on a server.

    Registry Tip: Current Template File

    The name of the security template applied by Setup or manually applied to the Secedit database is stored in the Registry under HKLM | Software | Microsoft | Windows NT | CurrentVersion | Secedit | TemplateUsed.

    You can use these prepackaged security templates to analyze the settings on a system and to upgrade a system with new security settings. This should only be necessary if you manage a standalone server. A domain member should be managed using group policies.

    Security Configuration and Analysis Snap-In

    An MMC snap-in called Security Configuration and Analysis permits you to compare the current local security settings with the contents of a security template. You can also use this snap-in to apply the security settings in the template.

    To use the snap-in, you must build a custom MMC console. After the console is built, you load a security template and use it as a benchmark for comparison with the current security settings. Any differences are identified for your attention with big red icons. Figure 12.19 shows an example. If you like the settings in the security template, you can choose to apply them. To perform these tasks, follow the steps listed in Procedure 12.6.

    Procedure 12.6 Using the Security Configuration and Analysis Snap-In

    1. Open an empty MMC console by entering MMC at the Run window.

    2. From the console menu, select Console | Add/Remove Snap-in. The Add/Remove Snap-in window opens.

    3. Click Add. The Add Standalone Snap-in window opens.

    4. Select both the Security Configuration and Analysis snap-in and the Security Templates snap-in.

    5. Close the window to return to the Add/Remove Snap-in window. The two snap-ins are on the list. There are no extensions.

    6. Click OK to save the additions and return to the MMC console.

    7. Select Console | Save As and save the console with a descriptive name, such as Security Analysis.msc.

    8. Expand the tree for both snap-ins. The Security Templates node displays a list of the security templates in \Windows\Security\Templates. The Security Configuration and Analysis node shows a set of instructions for performing an analysis.

    9. Expand the tree under one of the templates and examine the settings under Account Policies and Local Policies. You can modify the template settings if you want to tailor it to your situation. You should save the result as a new template.

    10. Right-click the Security Configuration and Analysis icon and select OPEN DATABASE from the flyout menu. The Open Database window opens.

    11. Type in the name for a database that will store the result of your analysis. Do not try to open the existing Secedit.sdb database. You will get an access denied error if you try.

    12. Right-click the Security Configuration and Analysis icon and select ANALYZE COMPUTER NOW from the flyout menu. The Perform Analysis window opens with a path for the analysis log.

    13. Click OK. When the analysis is complete, expand the tree under Security Configuration and Analysis to show the security settings. Where there is a difference between the local settings and the template settings, you'll see a red icon.

    Figure 12.19. Security Configuration and Analysis console showing highlighted differences between security configuration template and computer settings.


    Distributing Security Templates

    If you have standalone serverssuch as servers in a DMZ or application servers that you don't want to put in a domain or servers running Windows Server 2003 that are members of a classic NT domainyou can distribute security updates to these machines via the security templates and the Secedit utility.

    The Secedit utility has four options, each implemented as a command-line parameter:

    • Analyze. Compares the existing security settings with a template file and writes the output to an SDB database of your naming and a log file of your naming. The syntax is as follows:

      secedit /analyze /db somename.sdb /cfg template.inf /log somename.log
    • Configure. Updates the existing security settings with the contents of a template file. You can select particular areas out of the template rather than applying the entire contents. The results are saved to a database file of your naming.

      Warning: Applying a template can make your machine either much too insecure or lock it down so severely that you cannot get in. Proceed with caution if you use this option. The syntax is as follows:

      secedit /configure /db somename.sdb /cfg template.inf /log somename.log /area area1 area2
    • Export. Takes the current security settings and writes them to a template file. This comes in handy when you want to configure a group of servers with the same security settings. Configure the security on one machine the way you want it, then clone off the settings into a security template and distribute the template along with Secedit. The syntax is as follows:

      secedit /export /cfg template.inf /log somename.log
    • Validate. Takes the contents of a template and ensures that the syntax is correct for importing. The syntax to run this command is as follows:

      secedit /validate template.inf

    You can use Secedit to deploy template files to Windows Server 2003 computers in a classic NT4 domain by placing the Secedit.exe file and the template in the Netlogon share on each domain controller, then adding a line to the logon script to apply the configuration. Be sure to set up your logon scripts so you only apply this command to servers running Windows Server 2003. (You could design multiple templates and use branching in your logon script to select the proper platform, but this is fairly difficult to do in standard batch files.)

    Security Policy Highlights

    Here are key points to remember about the way security policies are applied to local systems:

    • Security policies for a local machine are stored in the Security Editor database, \Windows\Security\Database\Secedit.sdb.

    • Security group policies are always downloaded regardless of the link connection speed.

    • Account policies such as password history, password complexity, lockout policies, and so forth must be defined in the Default Domain policy. These policies are linked to the Domain container in Active Directory and cannot be altered by any other group policy.

    • Local security policies are put in place by Setup and during domain controller promotion based on security templates stored in \Windows\INF.

    • Local security policies can be modified with the SECEDIT utility using security templates stored in \Windows\Security\Templates as a reference.

    Administrative Template Policies

    The most obvious use for Administrative Templates is to hack the Registry on hundreds or thousands of machines at the same time. We've already seen most of the machinery involved with creating and managing Administrative Template policies. Here's a quick rundown of their operation before examining the details:

    • The Group Policy Editor (GPE) displays Administrative Template settings based on the content of ADM template files. These ADM files are located in the \Windows\INF folder.

    • When you enable or disable an Administrative Template policy, the GPE makes an entry in a GPT file called Registry.pol. This file resides in Sysvol under the policy folder. There are two copies of Registry.pol in each policy: one under the Machine folder that holds Computer Configuration policies and one under the User folder that holds User Configuration policies.

    • Clients affected by a GPO containing Administrative Template entries download the Registry.pol files and process their contents into the special Policies keys in the Registry.

    • Applications coded to look for parameters in the volatile Policies keys change their operation based on the contents of the group policy.

    Let's see how this process works in a little more detail. You want to get very familiar with Administrative Template processing. Most of the distributed management features in Windows Server 2003 rely on Registry-based policies in one form or another.

    Special Registry Keys Used for Policies

    Administrative Template policies in Registry.pol are written to special locations in the Registry designed to accept volatile group policy entries. Four keys store these volatile policies. Computer Configuration policies are written to the HKLM keys, and User Configuration policies are written to the HKCU keys:

    • HKLM | Software | Policies

    • HKLM | Software | Microsoft | Windows | CurrentVersion | Policies

    • HKCU | Software | Policies

    • HKCU | Software | Microsoft | Windows | CurrentVersion | Policies

    Values in these volatile Policies keys are refreshed each time the computer starts and users log on. If you remove an Administrative Template policy from a GPO or break the link to a GPO containing Administrative Template policies, the entries are removed from the local volatile Policies keys in the client's Registry. This eliminates the tattooing that plagued classic system policies.

    Tattooing and Classic System Policies

    Here's an example of system policy tattooing. Using classic NT system policies, it is possible to define a wallpaper bitmap for a group of users. If you make a user a member of the affected group, the policy is applied to the user's HKCU Registry hive and the wallpaper setting takes effect.

    If you remove the user from the group, the wallpaper setting stays in place on the user's desktop. You would either need to visit the local desktop to remove the wallpaper or define another group with a system policy to remove the wallpaper and make the user a member of that group.

    The situation is handled much more cleanly by group policies. First, you define the wallpaper policy by creating a GPO that has an Administrative Template policy called Active Desktop Wallpaper under User Configuration | Administrative Templates | Desktop | Active Desktop. You link this GPO to the OU containing the user accounts, and all the users get the wallpaper.

    If you move a user out of the OU, the policy setting disappears and the wallpaper returns to the original setting that preceded the group policy (the status quo ante, to use a Washington, DC, beltway term).

    Policies and Preferences

    The flexibility and lack of permanence associated with Registry-based group policies makes them an attractive feature, but there's an important thing to remember about them. They only work if the application you're trying to manage is coded to look for Registry values in the correct location. In other words, you cannot manage application XYZ with volatile group policies if XYZ doesn't know to look in one of the four volatile Policies keys in the Registry for its parameters.

    It is possible to use group policies to change Registry parameters outside of the volatile Policies keys. This creates hard-coded Registry entries similar to those created by classic NT system policies. Microsoft calls these non-volatile Registry entries preferences to contrast them with policies that can be added and removed freely.

    Policies are much more flexible and simple to manage than preferences; but if you are trying to manage legacy applications, often you must resort to preferences to control the Registry entries. We'll see how to create a preference, but first let's see how the Group Policy Editor creates standard policies.

    ADM Template Files

    Administrative Template policies get their name because their settings are derived from entries in a set of text-based ADM template files. This sounds similar to classic NT system policies, but the structure of the ADM files and how they are used are significantly different.

    The ADM template files are located in the \Windows\INF folder. The Group Policy Editor loads four of these templates by default:

    • System.adm. A comprehensive set of policy settings that control most of the features exposed by the Explorer shell.

    • Inetres.adm. Internet Explorer policies affecting components such as Internet Explorer, Control Panel, Offline Pages, Browser Menus, Persistence Behavior, and Administrator Approved Controls.

    • Conf.adm. NetMeeting policies.

    • Wmplayer.adm. Windows Media Player policies.

    Legacy Templates

    In addition to the standard ADM templates, Windows Server 2003 includes additional templates for backward compatibility with classic NT system policies. With one exception, these ADM templates cannot be loaded into the Group Policy Editor. They are accessed via the System Policy Editor, or Poledit. (The exception is Inetset.adm.) Following are the legacy templates you will find:

    • Inetset.adm. This template contains preferences for controlling Internet Explorer settings (see the earlier section, "Policies and Preferences," for more information).

    • Inetcorp.adm. System policies that control Internet Explorer languages, dialup restrictions, and caching.

    • Winnt.adm. System policies for NT4.

    • Windows.adm. System policies for Windows 9x.

    • Common.adm. System policies common to both NT4 and Windows 9x computer settings.

    Loading Additional ADM Templates

    If you purchase an application that makes use of volatile group policies, such as Office 2000 or Office XP, you can load the ADM templates into the GPE as described in Procedure 12.7.

    Procedure 12.7 Loading ADM Templates into the Group Policy Editor

    1. Open the Group Policy Editor for the GPO where you want to use additional templates.

    2. Expand the tree to the Administrative Templates icon (under either Computer Configuration or User Configurationit doesn't matter.)

    3. Right-click the Administrative Templates icon and select Add/Remove Templates.

    4. Click Add. The list of templates from \Windows\INF appears.

    5. Browse to the location where your templates are located and select the one you want to load.

    6. Close the Add/Remove Templates window to save the selection and load the template. (The template selection is saved as part of the MMC console settings so the template will be loaded the next time the console is opened.)

    7. Check to make sure that you can see the policies for the template you loaded. If the template is improperly formatted, you'll get an error when it loads.

    8. If the template contains only classic system policies with no processing instructions, it will be placed under a foreign policy icon and the contents will not be accessible.

    Poledit and Windows Server 2003

    Windows Server 2003 includes a copy of Poledit that you can use for creating and managing Config.pol and Ntconfig.pol files for your downlevel clients.

    Save the .pol files in \Windows\Sysvol\Sysvol\<domain_name>\Scripts. This folder is shared as Netlogon.

    A modern Windows machine (Windows Server 2003, Windows XP, or Windows 2000) that is a member of an NT4 domain will download and use system policies. As soon as the domain is upgraded to Windows Server 2003 or Windows 2000, all modern Windows machines stop using system policies and start using group policies.

    Group Policies and System Policies

    Windows Server 2003 users and computers only process classic system policies if they are not exposed to group policies from an Active Directory domain. Here are some examples:

    • A user in an Active Directory domain logs on to a Windows Server 2003 computer in an Active Directory domain: No system policies are processed.

    • A user in an Active Directory domain logs on to a Windows Server 2003 computer in an NT4 domain: The system processes Ntconfig.pol computer policies.

    • A user in an NT4 domain logs on to a Windows Server 2003 computer in an Active Directory domain: The system processes Ntconfig.pol user policies.

    Registry.pol Files

    When you enable Administrative Template policy settings in the Group Policy Editor (GPE), the GPE extracts the policy setting from the ADM template and uses it to create an entry in a file called Registry.pol. This file is a Unicode-based text file.

    The GPE presents three alternatives for setting a group policy: Enabled, Disabled, or Not Configured. Here is what the GPE writes to Registry.pol based on these three options:

    • Enabled. The GPE extracts a listing from the associated ADM template file and uses it to write an entry to Registry.pol. For instance, if you enable the Hide My Network Places Icon On Desktop policy, the GPE places the following entry in Registry.pol:

      [Software\Microsoft\Windows\CurrentVersion\Policies\Explorer ;NoNetHood  ; ; ; ]
    • Disabled. The GPE writes an entry to Registry.pol that negates the listing from the ADM file. For instance, if you disable the Hide My Network Places Icon On Desktop policy, the GPE places the following entry in Registry.pol:

      [Software\Microsoft\Windows\CurrentVersion\Policies\Explorer ;**del.NoNetHood ; ; ;]
    • Not Configured. The GPE removes all entries in Registry.pol related to the listing. This has no effect on other Registry.pol files, so that if the entry exists in another GPO, then the policy will be applied.

    When a client downloads this Registry.pol file, the entries are written to the volatile Policies keys specified in the template. This is done by the client-side extension Userenv.dll and requires no intervention by an administrator.

    ADM Listings Explained

    The listings in the group policy ADM files are coded to write their entries to volatile Policies keys. Here is an excerpt from System.adm to show how this works:

    CATEGORY !!Desktop
        KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"
        POLICY !!NoNetHood
           #if version >= 4
              SUPPORTED !!SUPPORTED_Win2k
           EXPLAIN !!NoNetHood_Help
           VALUENAME "NoNetHood"
        END POLICY
    NoNetHood="Hide My Network Places icon on desktop"
    NoNetHood_Help="Removes the My Network Places icon from the desktop.\n\nThis setting only 
    graphics/ccc.gifaffects the desktop icon. It does not prevent users from connecting to the network or 
    graphics/ccc.gifbrowsing for shared computers on the network."
    SUPPORTED_Win2k="At least Microsoft Windows 2000"

    To make the ADM template more readable, Microsoft makes generous use of string tokens. When you see a double-bang (!!) next to a word, you know that it is a string token. The end of each ADM file has a list of the string tokens and their expanded versions.

    Here is a quick explanation of the various elements of this ADM listing:

    • CLASS USER. Identifies the listings that follow as sub-icons under the User Configuration icon in the Group Policy Editor.

    • CATEGORY. Identifies the listings that follow as sub-icons under the icon name represented by the string token. In this case, the token !!Desktop expands to the same word, "Desktop".

    • KEYNAME. Identifies the listings that follow as having their Registry values in the identified Registry key. An individual listing can override this default KEYNAME entry with its own KEYNAME entry. Notice that the example shows a Registry value under one of the four volatile Policies keys, Software\Microsoft\Windows\CurrentVersion\Policies.

    • POLICY. The listing will appear in the GPE with an icon name represented by the string token !!NoNetHood. This string token expands to "Hide My Network Places icon on desktop".

    • SUPPORTED. This new keyword in Windows Server 2003 identifies which platforms support the policy. This keyword is used by a GPE filter that displays only selected policies.

    • EXPLAIN. This contains a help message that is displayed along with the policy listing in the GPE. The text is displayed on the Explain tab of the policy and in the sidebar of a web-enabled MMC console. The string token !!NoNetHood_Help expands to the full help text.

    • VALUENAME. This contains the exact value that will be written to Registry.pol when this listing is enabled. The default value type is REG_SZ. An option NUMERIC= entry can identify the value as REG_DWORD or REG_BINARY.

    When a client downloads a Registry.pol file containing this entry, the client-side extension will write the following Registry value:

    Key: HKCU | Software | Microsoft | Windows | CurrentVersion | Policies | Explorer
    Value: NoNetHood

    The My Network Places icon will now be missing from the desktop (for Windows Server 2003) and the Start menu (for XP desktops). Remember that the only reason this works is because Explorer is coded to look for this particular Registry value when building the desktop interface for a user. There are literally hundreds of Registry entries used by Explorer but only a few dozen are coded to look at policy values.

    Policies and Preferences

    It's possible to create your own ADM template with listings that write to locations other than the volatile Policies keys. These entries will be processed by the client-side extension just like ordinary group policies, but the result will be an entry poked directly into the Registry.

    Microsoft uses the term "preference" to describe a group policy that writes to the Registry outside of the volatile Policies keys. A preference is identified in the Group Policy Editor by a red dot in the icon. Standard group policies get a blue dot.

    A convenient way to view red-dot preferences is to load the Inetres.adm template. This template contains listings that write to Registry keys other than the volatile Policies keys. The contents display as red-dot preferences.

    A standard policy is also called a managed policy. By default, the GPE only displays managed policies. To display red-dot preferences, right-click the Administrative Templates icon and select FILTERING from the flyout menu. In the Filtering window, uncheck the Only Show Policy Settings That Can Be Fully Managed option and save the change.

    At this point, you can view the red-dot preferences in the Inetres.adm template listings. They will show the following settings:

    • If you Enable a red-dot preference, the Registry.pol entry lists the entire Registry path. The client-side extension puts the entry directly in the designated Registry key.

    • If you Disable a red-dot preference, the Registry.pol file entry is changed to have a **del prefix, and the client-side extension removes the entry from the Registry.

    • If you set the preference to Not Configured, the last setting you put in the Registry remains.

    It's very important that you get rid of a preference by first disabling it and waiting for the clients to download the policy before changing the status to Not Configured.

    Creating Custom ADM Templates

    You can build your own ADM templates by cutting and pasting from existing templates. Before you do, check to make sure that the policy does not already exist somewhere. The Help and Support utility lists all policies. The Resource Kit has a group policy help file (Gp.chm) that lists them in a more concise way.

    Remember: Writing a template entry that places a value in the Policies key only affects applications that are coded to look there. For the most part, all of these values have existing entries in the ADM templates. If you write a template entry that places a value in any other place in the Registry, the GPE will create a red-dot preference.

    Software Deployment Policies

    If you believe the hype in the trade press, the 21st century is the dawn of the Age of the Application Services Provider. Even if this is true, it's bound to be a long, long time before all the applications in your enterprise have migrated over to browser-based interfaces. Until that time arrives, if ever, we administrators dream of being able to wave a magic wand that can deploy desktop applications to the right user at the right computer in a configuration that works correctly right after being launched.

    Software deployment in Windows Server 2003 isn't quite the stuff that dreams are made of, but it certainly beats walking from cubicle to cubicle with stacks of CDs. This topic covers the mechanisms for software deployment in Windows Server 2003 and the requirements for the deployment packages.

    ADM Templates Can Be Unexpectedly Overwritten

    Each time the Group Policy Editor opens a policy, it refreshes its local copy of the ADM templates with the master templates in \Windows\INF. For this reason, you should avoid modifying existing templates. Instead, create new ADM templates and keep them in a central location where they can be accessed by any administrator who modifies a GPO.

    Alternative Software Deployment Tools

    Policy-based software is good at distributing files, but that's about it. If your deployment needs are complex or you require extensive monitoring and reporting capabilities, I highly recommend that you look elsewhere for a tool. Candidates include:

    • System Management Server (SMS) from Microsoft

    • Tivoli from IBM

    • ShipIT from Computer Associates

    • InstallShield enterprise deployment products

    • Mobile Automation

    Software Deployment Functional Description

    Like most policy-enabled features, software deployment depends on a confederation of components:

    • Windows Installer service. A service that distributes the constituents of an application package and makes the proper Registry entries to support the installation. Versions are available for NT4, Windows 9x, and ME, but the policy-based software deployment in Windows Server 2003 requires Active Directory-aware clients. It cannot deploy to downlevel desktops such as Windows 9x or NT4.

    • Microsoft installer package (MSI). An installation bundle consisting of the application's files along with a file catalog and instructions that tell Windows Installer how to perform the setup.

    • Software deployment package (AAS). A group policy template file that contains the location of the MSI file and the instructions for how to deploy it. A Class Store object in Active Directory holds information about the software package.

    • Deployment server. The server where the MSI file resides. It does not need to be a server running Windows Server 2003, or even a Windows server, but it does need to have a shared folder that can be accessed by clients who get the software deployment group policy.

    Also, the deployed application must come bundled in an MSI file. (You can bundle legacy applications into a so-called ZAP file that is little more than a batch file for launching the application's setup program.)

    Windows Installer Service

    The Windows Installer service performs the following functions:

    • Checks versions for each file and counts references to the files to minimize problems caused by one installation overwriting another. The Installer works in tandem with the Side-by-Side (SxS) features in Windows Server 2003.

    • Performs a delayed installation by waiting until the user launches the program from the Start menu or double-clicks a data file with an associated extension.

    • Maintains a transaction log of the installation so that the installation can be seamlessly restarted following an interruption. This includes the ability to roll back to a previous state even within the installation itself.

    • Maintains a catalog of all installed components and Registry changes so the application can be thoroughly removed if it is de-installed. This feature supports a group policy option that removes an application when a user is taken out of the scope of the GPO containing the distribution policy.

    • Supports self-healing applications by automatically downloading components that are accidentally deleted or overwritten.

    • Can install applications using elevated permissions. This enables the user to install an application without local administrator privileges. (Did I hear you say, "Hallelujah!"?)

    MSI Bundles

    Policy-based software deployment depends on the Windows Installer service, and Windows Installer requires that an application be bundled into an MSI file.

    All the components of the application need not be included directly in the MSI, but they must be present in a location that Windows Installer can find based on instructions in the MSI. Typically this means that the files and subfolders under the MSI need to be present in their standard configuration.

    You can often tailor the installation of an MSI bundle with Microsoft Transform (MST) files. These files provide a scripted installation of the base MSI bundle. For example, the Office Resource Kit (ORK) has a tool for walking through the setup screens for Office 2000 or Office XP and saving the selections in an MST file.

    Creating Roll-Your-Own Deployment Bundles

    Any application bearing the Windows 2000 or Windows Server 2003 logo must have an MSI bundle. This excludes quite a variety of software, though. If you want to deploy 32-bit Windows applications that do not have an MSI, you can create your own using a variety of tools. Following is a list (in ascending order of expense but not necessarily of features) of what is available:

    Elevated Privileges for Software Installation

    The capability of the Windows Installer to install an MSI package using elevated privileges eliminates a key source of desktop support calls.

    By default, an installation with elevated privileges is only enabled when deploying an application with group policies. You can set a group policy that permits the Windows Installer to install all MSI packages with elevated permissions. This lets you use third-party tools, even email attachments, to distribute software that can be installed by average users.

    The policy is called Always Install With Elevated Privileges. It is located under Computer Configuration | Administrative Templates | Windows Components | Windows Installer.

    Only the process thread that performs the installation is given elevated permissions, so you don't need to worry that a user will obtain inappropriate permissions by breaking into an installation. However, enabling this policy does open the possibility of a Trojan Horse program masquerading as an MSI package to nab elevated permissions. Don't enable this policy without giving some thought to your vulnerabilities.

    Software Deployment Package

    The Group Policy Template (GPT) file for a software deployment package comes in the form of a binary file with an .aas extension. This file is stored on Sysvol under the policy folder associated with the GPO.

    The deployment package tells the client-side extension where to find the MSI (usually via a network share identified by a UNC name) along with special handling instructions for the package. There are two ways a package can be deployed:

    • Published. The application becomes a menu selection in the Add/Remove Programs applet in Control Panel. Users double-click entries for applications they want to install, and the Windows Installer service takes over to run the MSI bundle from the distribution server.

      If you publish many applications, you can help your users sort through them by assigning categories. To enter categories for published applications, open the Properties window for the Software Distribution icon and select the Categories tab.

    • Assigned. The installation package places the appropriate shortcuts in the Start menu and registers the application in the Registry as if the application were actually installed. When the user selects the Start menu item or double-clicks a data file with the associated extension, the Windows Installer service takes over to run the MSI bundle from the distribution server.

    In either case, the applications are installed so that the distribution server is not overwhelmed during peak logon hours. You can use the Advanced option of the software deployment policy to set an option that forces the installation of an Assigned package as soon as the user logs on. This is handy if you want to make sure that everyone has the most current version of a client frontend after you've upgraded the backend application.

    The Advanced option also exposes these features:

    • A support URL option for published application where users can click to get more information about the application.

    • The option to uninstall the application if the user object is moved from the container linked to the GPO.

    • The option to remove existing installations of an application that were not installed using group policies.

    • Instructions for upgrading existing deployments of the application.

    • The ability to designate MST (Microsoft Transform) files or other modifications to the base MSI bundle.

    Software Deployment Troubleshooting

    If you have problems getting a software deployment package to work, start by making sure that all other group policies in the same GPO are being applied. If so, check that the MSI file is accessible by the client and that you yourself can get the package if you put your own object into the linked container. If all of this looks right, break out the big guns: diagnostic logging and the ADDIAG utility.

    Application Management Diagnostic Logging

    The Appmgmt client-side extension is responsible for downloading and processing .aas deployment packages. You can enable diagnostic logging for Appmgmt so that you can trace its operations and find any errors or problems it encounters.

    Enabling diagnostic logging requires a Registry change. Create the following key and value:

    Key: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
    Data: AppMgmtDebugLevel (REG_DWORD)
    Value: 4b

    This creates a log called Appmgmt.log in the \Windows\Debug\Usermode folder.

    Windows Installer Diagnostic Logging

    After Appmgmt has downloaded and processed the .aas package, Windows Installer takes over to process the MSI bundle. Enabling diagnostic logging for the Windows Installer will tell you precisely what it tried to do to install an application along with any errors that occurred. This also requires a Registry change. Add the following value:

    Key:   HKLM | Software | Policies | Microsoft | Windows | Installer
    Data:  Logging (REG_SZ)
    Value: voicewarmup

    The letters in the Value field each have a meaning. They can be in any order. Following are their functions:

    I Status messages

    w Non-fatal warnings

    e All error messages

    a Startup of actions

    r Action-specific records

    u User requests

    c Initial UI parameters

    m Out-of-memory or fatal exit information

    o Out-of-disk-space messages

    p Terminal properties

    v Verbose output

    + Append to existing file

    ! Flush each line to the log

    * Selects all options except v

    l*v Wildcard with verbose option

    This creates a log in the default %TEMP% folder. The log name starts with MSI followed by a sequence number with a .log extension.


    The ADDIAG utility comes in the Support Tools. It gives information about what MSI packages are installed on a client and where they came from. Here's a listing that shows the report breakdown:

    <Info>Dumps general information
    <TS>Dumps Terminal Service information
    <LocalApps>Dumps local managed applications list
    <ServerApps>Dumps server deployed applications list
    <MSIApps>Dumps local mSI applications list
    <GPOList>Dumps local GPO list
    <ScriptList>Dumps local script application list
    <ADHistory>Dumps local AD policy history
    <MSIFeatures>Dumps local MSI features list
    <MSILnks>Dumps MSI shortcuts in the profile
    <EventDump>Dumps application log-related events
    <Check>Performs an AD integrity check

    Here is an example ADDIAG listing that shows the information it collects:

    Z:\Program Files\Support Tools>addiag /v
    Microsoft (R) Software Installation Diagnostics. Version 1.00
    Copyright  Microsoft Corp 1998-1999. All rights reserved.
    Collecting info...
    Initializing Remote DS Data...
    Initializing Local AppMgmt Registry Data...
    Initializing Local AppMgmt File Data...
    Initializing Local Windows Installer Data...
    Initializing Local Shell Data...
    Initializing Local Event Data...
    ========================= General Info =========================
    User -- NameSamCompatible: COMPANY\phxuser1
    User -- NameFullyQualifiedDN: CN=phxuser1,OU=Phoenix,DC=company,DC=com
    User -- Logon Server: \\SERVER1
    User -- SID: S-1-5-21-2000478354-746137067-1957994488-1117
    User -- Profile Type: LOCAL
    User -- Locale: 1033
    Processor Architecture: x86
    System Locale: 1033
    ========================= TS Info =========================
    Not running TS
    ========================= Managed Apps (Local List) =========================
    No Managed applications were found.
    ========================= Managed Applications (Server) ========================
    User dump for COMPANY.COM
    Dumping GPO list (1 items)...
            GPO GUID: {B672BEFE-7815-44C4-9F28-E482AEC2CBAD}
            Name: Distro1
                    Administration Tools Pack
                            Object GUID: {D34A6C2A-5D4D-4005-85F6-CBDBB5136C57}
                            Package Flags:
                            ProductCode: {5E076CF2-EFED-43A2-A623-13E0D62EC7E0}
                            UI Level: Full
    ========================= Windows Installer Apps =========================
    Found 2 MSI application(s)
    Easy CD Creator 5 Platinum
    ========================= Local AD History =========================
    Found 1 Applied GPO(s) in the history
            GPO GUID: {B672BEFE-7815-44C4-9F28-E482AEC2CBAD}
            Version: 0xf000f
    ========================= Application log events =========================
    EventID:  1004
    Type: WARN
    Date: 20:32:41.0000 - 2/02/2002
    User: N/A
    Computer: PRO10
    Source: MsiInstaller
    Description: Detection of product '{5E076CF2-EFED-43A2-A623-13E0D62EC7E0}', feat
    ure 'FeDNSConsole', component '{455FE9A8-07D6-11D3-9C52-00A0C9F14522}' failed.
    The resource 'D:\Windows\System32\dnsmgmt.msc' does not exist.

    Folder Redirection Polices

    When users save their files, the application generally offers them a default location. If the application carries the Windows 98, Windows 2000, Windows XP, or Windows Server 2003 logo, it is required to offer the My Documents folder by default. This standardization helps control the clutter of files on a user's desktop, but it does not go the extra step of putting the files on a server where they can be backed up and scanned for viruses.

    This is also true of other folders in a user's profile. For example, the Desktop folder holds files and shortcuts that would be lost if the user's local drive died. The Application Data folder holds configuration information about programs loaded on the desktop along with other important data such as PKI keys. The ever-present Start menu holds shortcuts to every program loaded on the machine.

    You can centralize the storage and management of these critical Explorer components by storing them on a server. This is most easily done using folder redirection policies.

    A folder redirection policy takes the form of an Fdeploy.ini file that specifies the UNC name of the location where you want the system folder to reside. The client-side extension, fde.dll, processes the file by changing entries in the Registry associated with the Explorer shell folders. This changes the object namespace used by Explorer and other system components in Windows.

    From the users' perspective, this redirection is seamless. The only time they'll know that their files are not being saved locally is when the network connection gets broken. This happens frequently to laptop users, of course. You might want to take a look at using offline folders to store local copies of files in redirected folders.

    Script Policies

    Classic NT had only one way to deliver a logon script to a user. You created a script and placed it in the Netlogon share of every domain controller. You then modified the users' profiles to point at that script. You could only run one script, and the script could not be in any other location.

    Modern Windows changes this scripting situation considerably. Script policies permit you to run multiple scripts from any location. They also permit running logoff scripts for users and startup/shutdown scripts for computers.

    The system continues to support classic scripts for downlevel clients. Active Directory includes an attribute in the user object for a logon script. Downlevel clients obtain this script name when they log on. The domain controllers continue to host a Netlogon share to hold classic scripts. The shared folder has changed, though. Modern Windows shares the \Windows\Sysvol\Sysvol\<domain_name>\Scripts folder as Netlogon. Classic NT shares the \WINNT\System32\Repl\Import\Scripts folder.

    Classic Script Replication

    Anything stored in the Sysvol folder is replicated to all domain controllers in a domain, and scripts are no exception. However, if you are running in Mixed with downlevel Backup Domain Controllers (BDCs), you face a challenge.

    In classic NT, the contents of the Netlogon share on each domain controller were kept in sync using a service called LanMan Replication, or LMRepl. The LMRepl service replicated the contents of \WINNT\System32\Repl\Export on the PDC to the Import folder on the BDCs. It was this folder that was shared as Netlogon.

    Windows Server 2003 does not support LMRepl. To keep your scripts in sync, then, you must set up a classic BDC as the LMRepl export server in lieu of a PDC. (The PDC Emulator must be running Windows Server 2003 in a Mixed domain.)

    You must then use some method for copying the contents of the Scripts folder from the Windows Server 2003 PDC Emulator to the classic BDC export server. You can use Task Scheduler to kick off XCOPY or use one of the bulk copy utilities in the Resource Kit or a third-party tool. The LMBridge utility from the Resource Kit is especially useful.

    Script Types

    Scripts can take any form as long as the client is capable of interpreting the contents. This includes batch files (.bat) and command files (.cmd) along with more sophisticated scripting languages.

    Windows Server 2003 and XP support VBScript and JavaScript natively as part of the Windows Script Host (WSH) framework. You can also run other scripting languages such as Perl and Python by deploying the interpreters to the desktops. (The most current versions of ActivePerl and ActivePython come with MSI bundles to simplify installation. See www.activestate.com for evaluation copies.)

    VBScript and Viruses

    You are probably aware that many email viruses take advantage of the ubiquitous nature of VBScript support in Windows to run exploits. The I-Love-You virus and the AnnaKornikova virus are two examples. To be fair, this is not a weakness of VBScript. If Microsoft had chosen to distribute ActivePerl on every Windows desktop instead of VBScript, then the exploits would use Perl.

    You can set group policies in Windows Server 2003 to disable running VBScript attachments in email, but this does not preclude other vulnerabilities. Another solution, suggested by Jason Fossen from SANS, is to change the file association for *.vbs files from the native Cscript/Wscript engine to a benign application such as Notepad.

    If you take this precaution, you can still use VBScript to code logon scripts. All you need to do is make the name of the script a parameter of the Cscript executable. Figure 12.20 shows what this would look like in the Edit Script window of the Group Policy Editor.

    Figure 12.20. Edit Script window in the Group Policy Editor showing a VBScript as a parameter of Cscript.exe.


    Deploying Scripts

    Script policies rely on two constituents:

    • A Script.ini file in the policy tells the client what scripts to run and where to find them.

    • The scripts themselves. You should always store your scripts with the policy folder so that they will be replicated to all domain controllers. This prevents clients from going across the WAN to download their scripts.

    To deploy a script, you must configure the Script.ini file using the Group Policy Editor. Do this by opening the Properties window for the script type you want to deploy. Figure 12.21 shows an example.

    Figure 12.21. Logon Script Properties window showing selected scripts.


    The Show Files option allows you to view the files in the Scripts folder. This is a quick and easy way to copy your scripts to the correct location in the policy folder. Otherwise, you have to drill down through Sysvol and guess at which of the GUID-named folders is the policy you want to update.

    After you've placed the script file in the Policies folder, use the Add button to add the script to the Script.ini file.

    Clients download the Script.ini file where the Gptext client-side extension processes it. The CSE then downloads scripts themselves, which run under a script engine based on their file association.

    If a client downloads scripts from several GPOs, the scripts all run at the same time. For this reason, you should not put entries in one script that depend on actions taken by another.

    Also, the users are presented with a desktop while their logon scripts run. This means you should not make shortcuts and other Explorer shell configurations that assume actions have been taken by logon scripts.

    Many organizations like using tiered logon scripts. For instance, the top-level domain admins might issue a script that makes certain standard desktop settings such as mapping drives and running certain standard welcome applications. The OU administrators want to piggyback onto this main script but they cannot assume that the drive mappings are in place before their scripts run.

    If you want to use tiered logon scripts, or if you want to block access to the desktop until all scripts have run, you can configure the system to run logon scripts synchronously rather than asynchronously. (See the earlier section in this chapter, "Synchronous Script Processing," for details.)

      Previous Section Next Section