RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


ASP.NET Configuration and Group Policy, Part 3: Using the Enterprise Library Manageable Configuration Extensions  : Page 3

This last installment of a three-article series discusses how to apply centrally imposed Windows Group Policy settings using the Manageable Configuration Provider.

Setting Configuration Values in Group Policy
After installing the administrative template, the next step is to set the values you require for the application settings. You do not, of course, have to set all of the values. Only settings enabled in Group Policy will replicate to Windows Registry, and therefore affect the application.

Figure 4. Setting Configuration Values: The figure shows the screens where you set configuration values for the Data Access and Caching Application Blocks in the Group Policy Object Editor.
Figure 4 shows an example of setting configuration values for the sample application. You can see that the settings for "Cache Manager" (the Isolated Storage cache manager and backing store added to the application configuration) are enabled. The controls in the dialog allow you to specify settings such as the expiration poll frequency, number of items to remove when scavenging, and the Isolated Storage partition name for storing cached values.

Figure 4 also shows the single setting available for the Data Access Application Block (the settings for each database connection are in child nodes below this node). The drop-down list shows all the available connections defined within the configuration, and you can set the default connection to use when code does not specify a connection.

Author's Note: The values available in the list are generated by the Enterprise Library configuration tools when you create the administrative template from your configuration file. This is why, if you change the configuration by adding new blocks or providers, you must remove the existing administrative template, generate a new template, and install the new template into Group Policy.

Figure 5: Registry Settings: The figure shows machine-level settings for the sample application in Windows Registry; only a few of the settings have been enabled and configured in Group Policy.
The settings you specify do not replicate immediately. You can log off the target machine and then log on again to force the application of local policies, or you can restart the target machine to force the application of domain-level policies. Otherwise, they will be applied during the next security policy update cycle.

After the Group Policy settings replicate, you can view the results in the Windows Registry Editor (regedit.exe). Figure 5 shows the section from the HKEY_LOCAL_MACHINE hive that contains the sample application settings specified in Group Policy. You can see that only those settings enabled within Group Policy appear in the registry, and they are arranged in the same hierarchy as in the Group Policy Object Editor.

Testing the Manageable Configuration Source
The sample application uses the Enterprise Library Manageable Configuration Source provider to make it Group Policy aware. When you run the application with no Group Policy settings enabled, or if you set the EnableGroupPolicies property of the Manageable Configuration Source to False, it displays the default behavior. The left-hand list box uses the default SqlClient database provider, whereas the right-hand one uses the OleDb provider (see Figure 6).

Figure 6. Sample Application: Here's the default behavior of the two lists populated from the Northwind database when Group Policy is not applied.
The connection strings differ because the code that populates the left-hand list does not specify a database provider type, and so the Data Access Application Block generates one using the type specified as the default in the Web.config file:

   Database db = DatabaseFactory.CreateDatabase();
However, the code that populates the right-hand list does specify a database provider type—the LocalOleDbConnection defined in the Web.config file:

   Database db = DatabaseFactory.CreateDatabase(
In addition, the code that runs when you click the Cache a Dataset to Disk button uses the default cache manager, as specified in the Web.config file:

   CacheManager diskCache = CacheFactory.GetCacheManager(); 
To see the effects of Group Policy, specify the settings in the Group Policy Editor for the Default database (in the Specify Database Block settings section) and the Default Cache Manager (in the Specify settings for Caching Block section). For example, select LocalOleDbConnection as the default database, and Custom Cache Manager as the default cache manager.

Author's Note: the Caching Application Block assembly provided in the bin folder of the sample application contains a custom cache backing store that writes caching data to a disk file, instead of placing it into Isolated Storage.

Now, when you run the example (after the settings replicate to Windows Registry), you'll see that the code that populates the left-hand list box is now using the OleDb database provider instead of the SqlClient provider. The Manageable Configuration Source reads this setting from the registry and exposes it as the DefaultDatabase property for the Data Access Application Block (see Figure 7).

Figure 7. Effect of Default Database Setting: The setting for the default database in Group Policy causes the application to use the OldDb provider for both lists.
Figure 8. Effect of Default Cache Manager Setting: The setting for the default cache manager in Group Policy changes the behavior of the application to use the custom caching backing store provider, which writes cached data to disk files instead of Isolated Storage.

In addition, if you now click the Cache a DataSet to Disk button, you will see two files appear in your C:\Temp folder (provided that you have this folder on your disk, and that ASP.NET has permission to write to it!). The Group Policy settings change the default cache manager from "Cache Manager," which uses the Isolated Storage backing store provider, to "Custom Cache Manager," which uses the custom file-based backing store provider (see Figure 8).

Other Group Policy settings you can experiment with in the sample application include:

  • Turning on or off the instrumentation implemented within Enterprise Library using the settings in the Instrumentation section. You can turn on or off event logging, performance counters, and WMI event generation.
  • Changing the connection strings for each of the database providers for the Data Access Application Block in the Connection Strings section under the Database node. If you specify an invalid connection string for the LocalOleDbConnection database provider, code in the application will write exception details to Windows Event Log.
  • Changing the settings for the Formatted EventLog Trace Listener in the section for the Logging Application Block. The sample application writes exception details to Windows Event Log if an error occurs when populating the right-hand (OleDb) list box from the Northwind database. For example, if you change the setting for the name of the log from the default of "Application" to "System" (or to a custom Event Log you create), the messages will appear there instead. You can also specify a remote machine where message will be logged (provided that the ASP.NET has the relevant permission), and change the message format in the Log formatters section.
  • Changing the settings in the Cryptography section for the hash provider and symmetric encryption provider used by the sample application. For example, you can turn on or off SALT hash generation, or specify a different symmetric encryption key file and scope.
So, Why Is All This Useful?
One of the strengths of Enterprise Library—besides the more obvious features such as providing you with ready-built and tested code that simplifies development—is that you can change the behavior of the application blocks and the core functionality through configuration. This reduces downtime and removes the error-prone task of updating the code and recompiling.

However, unless you store configuration centrally (for example, in a shared database), each instance of the application requires a local configuration file that defines the behavior of that instance. In a server farm for an ASP.NET application, or in an office where there are hundreds of desktop machines, application configuration files can (will) become out of synch as administrators (and users, if they have permission) edit the file to solve problems, debug code, or experiment with settings.

Group Policy lets you apply and enforce settings for an application, and ensures that all machines within an Active Directory forest or domain contain the correct settings. It is still possible for users that have access to the local configuration file to change the behavior (they could simply remove the Manageable Configuration Source provider from the configuration!), but otherwise, changing settings locally will have no effect.

In addition, Group Policy makes configuration updates easier, by letting administrators apply and deploy configuration remotely, removing the need to visit each machine, or manually deploy updated versions of the configuration files. And, when situations or requirements change, administrators can quickly apply new configuration settings to all machines. For example, if a database server should fail, it's easy to change Group Policy settings to point all the machines at a different database server.

Alex Homer is a director of Stonebroom, Ltd., a software development, consulting, and training organization. He was formerly lead technical author and reviewer for Wrox, specializing in Microsoft Web and database technologies. You can reach him through his Web site.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date