SQL Server Policy-Based Management : Management Studio

Policy Categories

sqlpbm — Mon, 07 Jul 2008 22:06:18 GMT

Policy categories have two purposes in SQL2K8: 1) organization of policies and 2) policy scope. In this posting we'll explore creating categories for each of these purposes.

Creating Categories

There are two ways to create a category: 1) the Manage Categories dialog and 2) The Policy Properties dialog.

To create a category from the Manage Categories dialog, connect Object Explorer to an instance of SQL2K8. Expand the Management node, right-click on the Policy Management and select Manage Categories.

This will launch the Manage Categories dialog. On this dialog you can create, update, and delete categories and change the subscription state for each category. I'll cover the subscription state later on.

To create a new category click in the Name field on the last row and type in the name for the category. This will create a new category which is mandatory for every database. Click OK to dismiss the dialog and you're done.

You can also create a new category from the Policy Properties dialog.

On the Description tab click New next to the Category field. This launches the new Create new category which accepts a category name. The category will be created as mandatory for all databases. You also use this dialog to assign a policy to a particular category. Use the category combo box to select a category.

Organizing Policies

There are a few key places where the use of categories simplifies certain actions.

Object Explorer Details

When the Policies folder is selected in Object Explorer, Object Explorer Details lists all of the policies on the system with a select set of properties, including Category.

The columns in Object Explorer Details can be sorted, just click on the column heading you wish to sort by.

Sorting on category can make it easier to perform certain operations.

Evaluate, Export, and Script are all valid operations on a set of policies. You could use ctrl-click to select multiple disjointed policies but I've found sorting to be quicker and less error prone.

View Policies Dialog

Right-click any object in Object Explorer and select Policies -> View to see the policies which apply (or can apply) to the selected object. The View Policies dialog is displayed.

Category is a property in the table which can be used to sort the policies. This makes it easy to see which policies in a particular category apply to the object or are in violation.

Evaluate Policies

The Evaluate Policies dialog allows you to manually evaluate one or more policies against a single object or against the computed target set (all objects the policies applies to).

This dialog includes the Category property which you can sort on. If you wish to run all of the policies in a particular category sorting them first prevents you from having to hunt and peck for each policy in a particular category.

In this section we looked at several places where using categories can expedite certain policy tasks. Now let's look at category subscriptions which controls the applicability of policies.

Delegation of Policy Applicability

Using categories databases can subscribe to certain sets of policies. Subscribe simply means that all of the policies in the category may apply or do not apply to the particular database. This is only applicable to policies which target databases or objects contained in a database. Policies which target the instance and instance objects (excluding database) are excluded from the subscription.

Categories can be configured for mandatory subscription, meaning all databases must subscribe to the category and cannot opt out, and non-mandatory subscriptions, meaning individual databases can opt-in/opt-out of policies in the category.

When a database subscribes to a category it's not implicit that all policies in the category apply to the database and all objects in the database. The policy may contain a target filter which eliminates certain objects from the scope of the policy. However, if a database does not subscribe to a category the database and all database objects in that databases are explicitly excluded from the scope of the policy.

There are certain situations where optional categories make sense. A set of policies may only apply to certain databases but the Policy Administrator doesn't know which databases the policies apply to. However the owner of the database does know and can choose which policy categories apply and which don't.

For example you may have a set of policies that only apply to reporting (read-only) databases, but only the database owner knows if their database is a reporting database (there is no database attribute to designate this type of database and therefore no way to construct a target filter). The Policy Administrator would create the policies for reporting databases in a category called "Reporting Database Policies". The category is configured to be optional. Each database owner can then choose to subscribe to the category or not.

Security Notice: You must be SA or DBO of the database to control policy category subscriptions.

This launches the Categories dialog.

Mandatory categories appear subscribed to and disabled - meaning they cannot be unsubscribed from. The "<Default>" category is always mandatory. Non-mandatory categories have the subscription checkbox enabled to allow the database owner to subscribe/unsubscribe as appropriate. When the category is expanded the list of policies in the category is displayed. To subscribe to the category select the checkbox under the Subscribed column and click OK.

Summary

Categories serve two purposes: 1) organization (group like policies together) and 2) policy scope. It's a best practice to categorize your policies by their purpose (such as industry compliance or security). Choosing to mark the categories as optional or mandatory depends on your particular situation.

Suggestion: If you have SQL2K and/or SQL2K5 servers in your topology and you want to create policies for these servers you can create policies on a SQL2K8 server. Create two non-mandatory categories, "SQL Server 2000" and "SQL Server 2005" and place each policy in the appropriate category. This will make it easier to track what the policies are for. If you automate the policies using PowerShell you can easily select the correct set of policies for each server version.

_____________

About the Author:
Dan Jones is a PM on the SQL Server Manageability team at Microsoft.

Using PBM Against SQL2K and SQL2K5

sqlpbm — Fri, 04 Jul 2008 22:32:56 GMT

We get this question a lot: can I use PBM against a SQL2K & SQL2K5 instances. The quick answer is yes but in a limited fashion. PBM is ultimately based on SMO (SQL Server Management Objects) and SMO supports SQL2K, SQL2K5, and SQL2K8. PBM relies on some changes to the DB engine which are not available in versions below SQL2K8, therefore, not all PBM functionality is available in SQL2K and SQL2K5.

Let's divide the PBM functionality into four key areas:

Authoring policies
Storing policies on a server
Automated policy evaluation
Manual policy evaluation

Authoring Policies

There are two ways to author a policy: connected and disconnect. Connected policy authoring is only supported in SQL2K8. When authoring in connected mode (Object Explorer is connected to an instance) the policy is stored on the server. There is no way to alternatively save the policy to the file system (other than exporting it after it's created on the server). Disconnected authoring saves the policy to the file system (as an XML file). This functionality is only available in SQL2K8 Management Studio. Since it doesn't require a connection to a back-end server you don't need an instance of SQL2K8 available. Therefore, authoring policies is somewhat dependent upon SQL2K8 - you need the toolset but not a server.

Storing Policies On A Server

There are two ways to store a policy on a server: create it on the server and import a policy XML file to the server. Both of these are only available on SQL2K8 servers.

Automated Policy Evaluation

Policy automation is dependent upon enhancements to dependent features only available in SQL2K8 (SQCLR, SMO, Agent and DDL Eventing.) Therefore, automated policy evaluation (Check on Change - Prevent, Check on Change - Log, and Check on Schedule) is only available on SQL2K8 servers. In addition, the automation requires the policy to stored locally on the server which is only supported on SQL2K8.

Manual Policy Evaluation

Manually evaluating a policy is a client-side operation (simply meaning it doesn't run in the context of the DB Engine service) and therefore it requires SQL2K8 Management Studio (or at least the SQL2K8 management stack - PBM & SMO APIs). There are four ways to manually evaluate a policy:

From Object Explorer in Management Studio
From Registered Servers in Management Studio
The PowerShell cmdlet Invoke-PolicyEvaluation
From the PBM API

Object Explorer (OE): Policy evaluation is supported from OE when connected to SQL2K5 and SQL2K8 servers (note: this may also be available when connected to a SQL2K server but I didn't have one available to me at the time of this writing to verify). You get the same Evaluation dialog in both cases. However, when connected to a SQL2K5 server there are no locally stored policies which means you need to select policies from file or from a SQL2K8 server.

Registered Servers (RegSrvrs): Policy evaluation is supported from RegSrvrs for SQL2K, SQL2K5, and SQL2K8 servers. You can evaluate policies that are saved to file or stored on a SQL2K8 server. You can also evaluate policies against a group of servers. The server group can contain mixed versions.

Invoke-PolicyEvaluation: This PowerShell cmdlet can be run against SQL2K, SQL2K5, and SQL2K8 servers. You just pass in the server name to the TargetServerName parameter. You can evaluate policies stored on a SQL2K8 server or on the file system. This blog post shows how to use the Agent PowerShell subsystem in SQL2K8 to create a job that runs a PowerShell script to evaluate policies against a group of servers. These servers can be SQL2K, SQL2K5 and SQL2K8 servers.

PBM API: The PBM API is a public API and contains methods for evaluating policies. This is exactly what we use under the covers for our policy evaluation. You can create your own .Net application which calls this API. Similar to the PowerShell cmdlet you need to pass in a connection to the server to evaluate. This connection can be a SQL2K, SQL2K5, or SQL2K8 connection. The details for how to do this (the code you need to write) is beyond the scope of this posting but is a good topic for a future posting.

Summary

When we designed PBM we accounted for the fact that not all customers immediately upgrade their environment - you have to deal with mixed environments. We wanted to be sure PBM would add value to these mixed environments but we also need to give you a reason to upgrade :-). Therefore, we enable you to run policies against SQL2K and SQL2K5 just not with the same fidelity as SQL2K8.

Creating A Policy With the GUI

sqlpbm — Sun, 27 Apr 2008 04:44:25 GMT

In the previous posting we introduced the main PBM concepts through the use of a sample policy: All stored procedures in the database must start with "usp_". In this posting we will walk through the creation of that policy using the PBM GUI accessible from SQL Server Management Studio (SSMS).

The first step in creating the policy is to create a condition. To do this we use Object Explorer to navigate to the Policy Management node.

Right-clicking on the Conditions folder we select New Condition... which launches the New Condition dialog.

First we give our Condition a name. Conditions can be reused by multiple policies so we want to give it a meaningful name. Since conditions define the desired state of the system we'll give it a name in the positive. Something like SP Name Prefix usp_ should do. Next we have to pick which facet we want to build our expression over. Remember, facets define two things for us: target types and properties. We have a choice of three facets: Stored Procedure, Multi-Part Name, and Name. For this example we'll pick the Multi-Part Name facet.

Now that we have our condition created we right-click on the Policies node in OE and select New Policy... We give our policy a name and select the condition we created above. We also could have started from the New Policy dialog and launched into the New Condition dialog.

We want to ensure no stored procedures are created on the system which violate the policy, therefore, we choose the On change: prevent evaluation mode.

Next we need to choose which targets the policies applies to. Because we built our condition on the multi-part name facet we see all of the targets which support that facet. We select Stored Procedure since that's the only one we care about for this example.

On the Description tab we can enter a description for the policy and a link (http, https, and mailto) for where to go for additional help.

After we enter this information click OK to save the policy. The policy and condition show up in Object Explorer.

Now we can attempt to create a stored procedure which violates our policy. In this example we create a nonsensical SP but the important point is the name, MyProcedure. Since our policy states names must start with 'usp_' our procedure should not be created. And that's exactly what happens. Let's take a closer look at the information we get back. First, the message tells us which policy we violated along with which object violated the policy. We also see the condition, policy description, and the link for additional help. All of this is useful information if the person is not familiar with the policy. The statement which violated the policy is included in the output. If this was a long SQL script this can help us trouble shoot the offending code.

This simple example showed you everything you need to get started using Policy-Based Management. Though our condition was straightforward they can get quite complex. In future postings we'll explore building more complex conditions in addition to some of the other advanced capabilities of Policy-Based Management.

_____________

About the Author:
Dan Jones is a PM on the SQL Server Manageability team at Microsoft.