Expose application policies through the Group Policy snap-in

Benefits

• Saves development time by using the system provided administrative tool for policy editing.
• Common user interface reduces administrator learning curve.
• Expedites deployment and change management of applications.

Description

Now you’ve enabled application policies in your program you’ve solved part of the TCO problem, but you need to provide the administrator with a way to set all the great policy options you’ve provided.

The way to handle this is to expose your application policies through the Group Policy snap-in using an administrative template (.adm) file. The .adm file specifies the registry settings that can be modified via the Group Policy snap-in.

Administrative template files have a number of advantages:

• Leverage the existing Group Policy snap-in UI

• The .ADM file format has been extended to allow more control over policies.

• Allows for backwards-compatibility with down-level clients such as Windows NT4.0, Windows 98, and Windows 95 by using the “#IF VERSION” statement.

You should always supply .adm files with your application if you provide policy. There are however, certain situations when the functionality provided by .adm files isn’t enough; when you need UI features beyond those provided by the Group Policy snap-in for instance. In these cases you can write a Microsoft Management Console (MMC) snap-in to provide the extra functionality that you need. Be aware though, that MMC Group Policy snap-in extensions do not work with down-level clients.

Code Sample

CLASS MACHINE

CATEGORY  !!UserProfiles
    KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\winlogon"
    POLICY !!DeleteRoamingCachedProfiles
        VALUENAME "DeleteRoamingCache"
        PART !!DeleteCache_1 TEXT  
        END PART
        PART !!DeleteCache_2 TEXT  
        END PART
    END POLICY

    POLICY !!EnableSlowLinkDetect
        VALUENAME "SlowLinkDetectEnabled"
    END POLICY

    POLICY !!SlowLinkTimeOut
        PART !!SlowLinkWaitInterval NUMERIC REQUIRED
            MIN 1 MAX 20000 DEFAULT 2000
            VALUENAME SlowLinkTimeOut
        END PART
    END POLICY

    POLICY !!SlowLinkDefault
        PART !!DefaultOperation DROPDOWNLIST REQUIRED
            VALUENAME "SlowLinkProfileDefault"
            ITEMLIST
                NAME !!PD_DOWNLOAD VALUE NUMERIC 1
                NAME !!PD_USELOCAL VALUE NUMERIC 0
            END ITEMLIST
        END PART
    END POLICY

    POLICY !!ChooseProfileDefault
        PART !!DefaultOperation DROPDOWNLIST REQUIRED
            VALUENAME "ChooseProfileDefault"
            ITEMLIST
                NAME !!PD_DOWNLOAD VALUE NUMERIC 1
                NAME !!PD_USELOCAL VALUE NUMERIC 0
            END ITEMLIST
        END PART
    END POLICY

    POLICY !!ProfileDlgTimeOut
        PART !!ProfileDlgWaitInterval NUMERIC REQUIRED
            MIN 0 MAX 600 DEFAULT 30
            VALUENAME ProfileDlgTimeOut
        END PART
    END POLICY
END CATEGORY

[strings]
UserProfiles="Windows NT User Profiles"
DeleteRoamingCachedProfiles="Delete cached copies of roaming profiles"
DeleteCache_1="When users with roaming profiles log off,"
DeleteCache_2="delete the locally cached profile to save disk space."
EnableSlowLinkDetect="Automatically detect slow network connections"
SlowLinkTimeOut="Slow network connection timeout"
SlowLinkWaitInterval="Time (milliseconds)"
SlowLinkDefault="Slow network default profile operation"
DefaultOperation="Default option"
PD_DOWNLOAD="Download profile"
PD_USELOCAL="Use local profile"
ChooseProfileDefault="Choose profile default operation"
ProfileDlgTimeOut="Timeout for dialog boxes"
ProfileDlgWaitInterval="Time (seconds)"

Considerations

Avoid using binary data in policies. It’s okay to use binary data for Yes/No values, but don’t use binary data for something like list index values. For example, let’s say you have a policy for the default color scheme, rather than having a numeric list index value such as ColorScheme = 0, you should have ColorScheme = Red (or the appropriate local string).

Avoid packing multiple settings into one key using bitfields. If you want to have a setting for UserCanSelectColorScheme and UserCanSelectStocks, they should be separate, each with its own true/false value. Don’t combine them into one field, UserSelectOptions, and OR the values together. However, if you have a policy for something like MaxCacheSize you should store that as a number (binary data).

If performance absolutely demands the use of binary data, make sure the application comes with a MMC Snap-In for easier editing. A policy that isn’t easily set and applied may as well not be there.

See Also

Administrative Template File Format, Microsoft Management Console: Overview, MMC Snap-in extensions