Inside Windows Server 1002003 [Electronic resources] نسخه متنی

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.

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.

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.

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 O

    PEN D

    ATABASE 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 A

    NALYZE C

    OMPUTER N

    OW 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.

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.

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.

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:

[View full width]
CLASS USER
CATEGORY !!Desktop
KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"
POLICY !!NoNetHood
#if version >= 4
SUPPORTED !!SUPPORTED_Win2k
#endif
EXPLAIN !!NoNetHood_Help
VALUENAME "NoNetHood"
END POLICY
END CATEGORY
[strings]
Desktop="Desktop"
NoNetHood="Hide My Network Places icon on desktop"
NoNetHood_Help="Removes the My Network Places icon from the desktop.\n\nThis setting only 
affects the desktop icon. It does not prevent users from connecting to the network or 
browsing 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 F

ILTERING 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.

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.

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.

ADDIAG

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:
Published
PostBeta3
UserInstall
OnDemandInstall
OrphanOnPolicyRemoval
ProductCode: {5E076CF2-EFED-43A2-A623-13E0D62EC7E0}
UI Level: Full
========================= Windows Installer Apps =========================
Found 2 MSI application(s)
Easy CD Creator 5 Platinum
WebFldrs
========================= Local AD History =========================
Found 1 Applied GPO(s) in the history
Distro1
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.
Data:

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.)

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.

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 runSynchronous Script Processing," for details.)