Provide application policy

TCO is fast becoming the “hot” issue in corporate environments today. By offering application policies, you make your application easier and cheaper to manage, more flexible, and better suited to life in the corporate environment.

Through application policies you can include ways to disable/enable features, offer work-group specific settings such as common documents folder for the default Open/Save folder, append corporate settings like help desk numbers to error messages etc, the list goes on! The choices administrators make can then be applied to specific groups or company wide.

The subsequent sections discuss the guidelines for offering application policies. The main topics we will cover are:

• Allow administrators to set application policy defaults. While allowing users to set options is generally a good thing, it can lead to problems caused by incorrect configurations. Often this requires a helpdesk call, or on site intervention by support staff. Providing Administrators with a way to set program defaults via policy, allows administrators to set a baseline configuration that works “out of the box”. Users can then customize their settings if they wish, but if things go wrong, they can always remove their customizations and have the administrator-set defaults to fall back on.
• Allow administrators to mandate application policy defaults. While allowing users to set options is generally a good thing, it can lead to problems caused by incorrect configurations. Often this requires a helpdesk call, or on site intervention by support staff. Providing Administrators with a way to set mandated program defaults via policy, allows administrators to set a baseline configuration that works “out of the box”. Unlike default policy settings, users cannot change their mandated settings.
• Expose application policies through the Group Policy snap-in. 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.
• Allow features to be turned off. You’ve spent all this time coding cool new features, why on earth would you want to turn them off? Well, there are several good reasons, reducing excessive customization, allowing for easier rollout, and greater administrator control, to name a few.
• Reflect policy changes in your UI. Turning off features via policy is a great way to lower TCO. However, it is important to make sure your application’s UI responds in a positive way to features being turned off. If this isn’t done properly, you run the risk of actually increasing your TCO.
• Protect related policies with CriticalPolicySections. Policies that need to play together should stay together! Windows 2000 can update policies while an application is running, which means that if you want your policies to be read together, you need to protect them with CriticalPolicySections.
• Document application policy. Document, document, document. All of the cool new policy options you’ve provided are no use if no one knows about them!