Now that the November CTP is released let’s take a look at the new capabilities in DMF.
- The first thing you’ll probably notice is the Policy dialog received a facelift. We spent some focused time on the GUI to fine tune it and make it more user friendly. The layout is greatly improved with labels changing and the execution selections being more descriptive.
- A few things you’ll notice on the policy dialog are 1) the target filtering is enhanced. First you can filter on any target type (prior you could only filter on database). Second the filter is actually a condition on that type’s main configuration facet. This means you can reuse filters between policies. For example, you could create a filter (condition) for “Databases > 5GB” and reuse that on every policy you only want to apply to databases that are greater than 5GB. 2) The server filter is pulled out to it’s own control. The server filter also uses conditions built on the key server facets. This allows reuse as well. The server filter is important as you move policies out to multiple servers. For example, say you have a policy that’s only applicable to instances running on machines with more than 4 GB of RAM. You can create a server filter for this condition and not worry about which machines the policy is distributed to; it’ll only apply to machines that meet the condition.
- Custom policy help links. Flipping to the second tab of the policy dialog you’ll see two new fields: Display message and link. The link field accepts http://, https://, and mailto:// links. This information shows up when you violate a policy from the T-SQL editor. Also when you view the details of a policy from the history dialog you’ll see the policy description and the help link.
- Best Practice Policies: you’ll notice that the instance is installed with a default set of best practice policies along with their corresponding conditions. This is going to slightly change in the next CTP (they’ll be installed to the file system rather than to the instance – if you want them on the instance you’ll have to import them).
- Built-in Functions: we added a number of math, logic, and date functions for use in conditions. The enhances the expressiveness of Conditions.
- Scripts: we added the ability for a condition to use a T-SQL or WMI (WQL) script. The script will be evaluated at the time the condition executes. In this CTP you won’t be able to automate policies that reference conditions with scripts. But stay tunned as we’re working on lifting that restriction…
- Propererties on Both Sides: previous you could only select a property on the left-hand side of the expression. Now properties can exist on both sides. This will allow you to compare two properties. For example: Last Data Backup Date == Last Log Backup Date.
- Policy Groups become Policy Categories: Category better reflects the intent of the functionality than group. The first thing is we added GUI to control categories (right-click on Policy Management). Second, Prior to CTP5 if you want a policy to apply to all databases by default you had to put it in the <Default> group. In CTP5 you can create a category and force every database to subscribe to it. This frees you up to categorize your policy as you see fit and not worry about having to ensure every database subscribes to the group.
- Multi-Server On Demand Policy Execution: From the Registered Servers tool window you can right-click on a server or a server group and select to run a policy. This is currently limited to a single policy from file. But it’ll evaluate that policy against the server or the servers in the group.
We’ve covered a lot of ground in CTP5. And we have more in store for DMF in the coming CTPs. Most of the stuff we’re working on now is to provide deeper capabilities in existing functionality rather than add new raw functionality. For example, the ability to do actions on a set of policies rather than individual policies.