Troubleshooting Group Policy
Administrator Enters Invalid Values
Group Policy administrative tools, such as the Group Policy Editor and the Group Policy Management Console, do not perform custom validations, so they will allow an administrator to enter an invalid value in a string field, such as an incorrect type name.
Only policies having valid values on all settings are applied, so when an invalid value is detected, an entry is written to the event log and the entire policy is ignored. The problem is logged to the event log.
Application Is Modified Without Generating New Group Policy Template
If the application is modified, some configuration elements may be replaced with new elements that have the same names, but different types. In this case, the manageable configuration source will look for the policies of the new element, but it will find policy settings for the original configuration elements, which may not match. Typically, this will result in missing values.
Policies Conflict to Produce Invalid Configuration
It is possible for different policies to conflict with one another. If this is the case, it will result in an invalid configuration after the Group Policy overrides are applied. This type of problem can easily occur, because different polices may be applied in different Group Policy Objects. In this case, the ManageableConfigurationSource instance does not detect an error. Typically, the consumer of the configuration settings logs the error.
Querying and Updating the WMI Repository
You can use Windows Management Instrumentation (WMI) to view and update a running application's configuration data when you use the Manageable Configuration Source to expose your Enterprise Library configuration. The Manageable Configuration Source reads information from the configuration file, applies any applicable Group Policy overrides, and exposes the configuration information to applications as a series of configuration class instances in the same way as the other Enterprise Library configuration sources.
However, the Manageable Configuration Source also exposes the configuration information through the .NET WMI 2.0 API and to the WMI Repository as a set of WMI classes that you can query and view. This allows administrators and users to examine configuration information using standard Windows-based management tools or code.
In addition, administrators and users can update the values of the WMI objects using standard Windows-based management tools or code. These changes update the configuration information exposed to the application by the Manageable Configuration Source, which also raises a ConfigurationChanged event that allows the application to react to the changes and reload the new configuration values.
Note:
You must have the relevant Windows permissions to update WMI objects. In addition, as changes pass back to the Manageable Configuration Source, it reapplies any relevant Group Policy overrides. If the change conflicts with a Group Policy setting, the Manageable Configuration Source will ignore the change and continue to expose the Group Policy-applied value.
Changes you make to the configuration exposed by the WMI objects are exposed by the Manageable Configuration Source and are visible in the application. However, they do not change the contents of the original configuration file. When the application restarts, or if you make changes to the configuration file contents, any updates made through WMI are lost.
The following table lists the ways you can query and update values in the WMI Repository.
Posted in: .Net Programming| Tags: Application Configuration Enterprise Library Group Manageable Policy Query Repository Source Update WMI file information managementAdding a Manageable Configuration Source
If you want to use Group Policy or Windows Management Instrumentation (WMI) with an application, you must first add a manageable configuration source. Although the procedures shown here use the Configuration Console, you can use the same procedures with the Configuration Editor that is integrated with Visual Studio. For more information about the Configuration Editor, see Using the Configuration Tools.
To add a manageable configuration source
Start the Enterprise Library Configuration Console or the Visual Studio Configuration Editor. To use the Configuration Console, click Start, point to All Programs, point to Microsoft patterns & practices, point to Enterprise Library 4.1 – October 2008, and then click Enterprise Library Configuration.
Click New Application or Open Existing Application.
Right-click the application configuration file listed under Enterprise Library Configuration, point to New, and then click Configuration Sources.
Right-click the Configuration Sources node, point to New, and then click Manageable Configuration Source.
Click the Configuration Sources node.
In the right pane, click SelectedSource.
In the drop-down list, click Manageable Configuration Source.
Click the Manageable Configuration Source node. In the right pane, set the configuration settings. By default, both WMI and Group Policy are enabled. You must provide an entry for the File property.
Right-click the System Configuration Source, and then click Remove.
On the File menu, click Save Application.
How to: Enable Local Cache (Code) (Velocity)
To programmatically enable local cache when creating your cache client, you must make sure the localCache parameter in the DataCacheFactory class constructor is equal to true. For more information about the application configuration settings, see Application Configuration Settings (Velocity).
Note
These procedures assume that you have already prepared your development environment and set references to the "Velocity" assemblies, and so on. For more information, see How to: Prepare the Development Environment (Velocity)
To create a cache client that has local cache enabled
Create an array of DataCacheServerEndPoint objects to specify the cache hosts for the client.
Configure your cache hosts by assigning the cache host array from the previous step to the servers parameter of the DataCacheFactory constructor. Note: For performance reasons, we recommend that you minimize the number of DataCacheFactory objects created in a cache-enabled application. Store the DataCacheFactory object in a variable available to all parts of the application that use cache clients.
Configure your cache client type by assigning a true or false value to the routingClient parameter of the DataCacheFactory constructor. Use the true value for a routing client, or a false value for a simple client.
Enable local cache by assigning a true value to the localCache parameter of the DataCacheFactory constructor.
(optional) Configure your cache client for cache notifications by using the DataCacheFactory constructor with the following additional parameters.
syncPolicy: Use the DataCacheLocalCacheSyncPolicy enumeration to choose how locally cached objects are invalidated. Use TimeoutBased to indicate that a time-out value should be used or NotificationBased to indicate that cache notifications will be used. For more information, see Cache Clients and Local Cache (Velocity).
localCacheTimeout: Use this parameter to specify the number of seconds that an object will remain in local cache before it is invalidated. This parameter is ignored if syncPolicy is set to NotificationBased.
pollInterval: Use this parameter to specify the interval of frequency, in seconds, that the cache client will check with the cache cluster for cache notifications. The default value is 300 seconds. Note: Local cache is not required for cache notifications. For more information, see Cache Notifications (Velocity).
Use the GetCache method to obtain an instance of the routing client.
Posted in: .Net Programming| Tags: .net 4.0 parameter Application Configuration CTP CTP 3 Microsoft Velocity cache code enable client local localcache