Today on Twitter my friend Jes “Run Forrest Run” Schultz Borland (Blog | Twitter) asked the Community “How do you clean up your dev environments? Let DBs sit out there forever? Delete after X months? Other? This seemed like an interesting issue to tackle and me being the PBM freak that I am, immediately I had a light bulb moment for a policy. In this post I’ll show you a policy you can run against your databases (can work in dev or whatever environment suits you) and will tell you which databases are older than 30 days old. As an added bonus, I’ll also show you how to add a custom extended property to set a custom expiration date.

Custom Expiration Date

First we’re going to modify our existing databases to define an expiration date. How are we going to do this? We’re going to add an extended property to our database. To do so on one database use the stored procedure sys.sp_addextendedproperty. The following code uses this stored procedure to add an extended property called ‘ExpDate’ with a value of ‘11/11/2011’.

EXEC AdventureWorks.sys.sp_addextendedproperty @name=N'ExpDate', @value=N'11/11/2011'

Why are we only doing this on one database? Well it will make more sense later when we run our policy against all our databases in our instance. Next up, the policy itself. As always I’m providing both the T-SQL for the policy or you can download the XML and import the policy directly.

Download ‘Expire Development Databases’ Policy Here

T-SQL:

--Create condition first
Declare @condition_id int
EXEC msdb.dbo.sp_syspolicy_add_condition @name=N'Databases older than 1 month', @description=N'', @facet=N'Database', @expression=N'<Operator>
  <TypeClass>Bool</TypeClass>
  <OpType>OR</OpType>
  <Count>2</Count>
  <Operator>
    <TypeClass>Bool</TypeClass>
    <OpType>GE</OpType>
    <Count>2</Count>
    <Attribute>
      <TypeClass>DateTime</TypeClass>
      <Name>CreateDate</Name>
    </Attribute>
    <Function>
      <TypeClass>DateTime</TypeClass>
      <FunctionType>DateAdd</FunctionType>
      <ReturnType>DateTime</ReturnType>
      <Count>3</Count>
      <Constant>
        <TypeClass>String</TypeClass>
        <ObjType>System.String</ObjType>
        <Value>day</Value>
      </Constant>
      <Constant>
        <TypeClass>Numeric</TypeClass>
        <ObjType>System.Double</ObjType>
        <Value>-30</Value>
      </Constant>
      <Function>
        <TypeClass>DateTime</TypeClass>
        <FunctionType>GetDate</FunctionType>
        <ReturnType>DateTime</ReturnType>
        <Count>0</Count>
      </Function>
    </Function>
  </Operator>
  <Operator>
    <TypeClass>Bool</TypeClass>
    <OpType>GT</OpType>
    <Count>2</Count>
    <Function>
      <TypeClass>DateTime</TypeClass>
      <FunctionType>ExecuteSql</FunctionType>
      <ReturnType>DateTime</ReturnType>
      <Count>2</Count>
      <Constant>
        <TypeClass>String</TypeClass>
        <ObjType>System.String</ObjType>
        <Value>DateTime</Value>
      </Constant>
      <Constant>
        <TypeClass>String</TypeClass>
        <ObjType>System.String</ObjType>
        <Value>SELECT value FROM sys.extended_properties&lt;?char 13?&gt;
WHERE name = ''''ExpDate''''</Value>
      </Constant>
    </Function>
    <Function>
      <TypeClass>DateTime</TypeClass>
      <FunctionType>GetDate</FunctionType>
      <ReturnType>DateTime</ReturnType>
      <Count>0</Count>
    </Function>
  </Operator>
</Operator>', @is_name_condition=0, @obj_name=N'', @condition_id=@condition_id OUTPUT
Select @condition_id

GO

--Now create the policy itself using the newly created condition
Declare @object_set_id int
EXEC msdb.dbo.sp_syspolicy_add_object_set @object_set_name=N'Expire Development Databases_ObjectSet', @facet=N'Database', @object_set_id=@object_set_id OUTPUT
Select @object_set_id

Declare @target_set_id int
EXEC msdb.dbo.sp_syspolicy_add_target_set @object_set_name=N'Expire Development Databases_ObjectSet', @type_skeleton=N'Server/Database', @type=N'DATABASE', @enabled=True, @target_set_id=@target_set_id OUTPUT
Select @target_set_id

EXEC msdb.dbo.sp_syspolicy_add_target_set_level @target_set_id=@target_set_id, @type_skeleton=N'Server/Database', @level_name=N'Database', @condition_name=N'', @target_set_level_id=0
GO

Declare @policy_id int
EXEC msdb.dbo.sp_syspolicy_add_policy @name=N'Expire Development Databases', @condition_name=N'Databases older than 1 month', @policy_category=N'', @description=N'', @help_text=N'', @help_link=N'', @schedule_uid=N'00000000-0000-0000-0000-000000000000', @execution_mode=0, @is_enabled=False, @policy_id=@policy_id OUTPUT, @root_condition_name=N'', @object_set=N'Expire Development Databases_ObjectSet'
Select @policy_id
GO

So let’s talk about this policy first before we run it. The condition on this policy is checking for two things. The first is to see if the creation date of the database is more than 30 days from the current date. Of course you can go into the condition and modify it to whatever you’d like but for the purposes of this post we’re using 30 days. Additionally we also have another clause using OR that is checking the value of the extended property field to see if that custom date is greater than the current date. How did we do this? We use the advanced editor in the condition creator and use the executesql function to query the database for the value of the ExpDate property. If no extended property exists for that database then the policy will simply use the 30 day condition clause mentioned earlier.

So now that we’ve seen the policy and its condition let’s see it in action! I’ve run this policy against the databases on my instance and we get mixed results here. Overall we see a bunch of databases that don’t pass the policy but we have one that does.

As you can see from the screenshots above, the policy that passed did so because it passed our secondary clause in our policy. The policy was run (at the time of this posting) on October 6th 2011. The expected expiration date from the first clause expects a date 30 days ago, which is September 6th. Our second clause, however, instead looks at the value of the extended property we set earlier. Since today’s date is less than that of the property set value of November 11th, the database is still considered to be current and active!

Next Steps

While this policy evaluation doesn’t let you take any action against the databases, this does give you a listing of what databases you should be paying attention to. This method lets you quickly identify which databases you should be “cleaning up” in your environments. You can schedule a policy like this to run only against your development environments by using the Central Management Server’s (CMS) functionality in conjunction with the Enterprise Policy Management Framework. The nice thing about using EPMFramework here is that results are saved in a database and you’re able to see those results in the great built-in reports. To see how to use CMS with Policy-Based Management, check out my webinar from the recent 24 Hours of PASS event!

At work recently, I explained to a coworker the reasons and benefits of having databases in Simple mode in your development environment. Funnily enough, a few hours later, I see my friend Andie Letourneau (Blog | Twitter) posted a blog on how to adjust your recovery modes in development. While Andie’s homework assignment is to substitute it with a WHILE loop, I have MUCH simpler solution using Policy-Based Management!

First, let’s create the condition and policy. As always you can either use this T-SQL or you can simply download the XML policy and import it:

Download Policy Here

TSQL:

--Create Condition First
Declare @condition_id int
EXEC msdb.dbo.sp_syspolicy_add_condition @name=N'Simple Recovery Mode', @description=N'Ensures databases are set to SIMPLE recovery mode', @facet=N'Database', @expression=N'
  Bool
  EQ
  2

    Numeric
    RecoveryModel

    Numeric
    Enum
    Numeric
    2

      String
      System.String
      Microsoft.SqlServer.Management.Smo.RecoveryModel

      String
      System.String
      Simple

', @is_name_condition=0, @obj_name=N'', @condition_id=@condition_id OUTPUT
Select @condition_id

GO

--Create Policy
Declare @object_set_id int
EXEC msdb.dbo.sp_syspolicy_add_object_set @object_set_name=N'Simple Mode Check_ObjectSet', @facet=N'Database', @object_set_id=@object_set_id OUTPUT
Select @object_set_id

Declare @target_set_id int
EXEC msdb.dbo.sp_syspolicy_add_target_set @object_set_name=N'Simple Mode Check_ObjectSet', @type_skeleton=N'Server/Database', @type=N'DATABASE', @enabled=True, @target_set_id=@target_set_id OUTPUT
Select @target_set_id

EXEC msdb.dbo.sp_syspolicy_add_target_set_level @target_set_id=@target_set_id, @type_skeleton=N'Server/Database', @level_name=N'Database', @condition_name=N'', @target_set_level_id=0

GO

Declare @policy_id int
EXEC msdb.dbo.sp_syspolicy_add_policy @name=N'Simple Mode Check', @condition_name=N'Simple Recovery Mode', @policy_category=N'', @description=N'This policy ensures that the databases evaluated against are set to SIMPLE recovery mode.', @help_text=N'', @help_link=N'', @schedule_uid=N'00000000-0000-0000-0000-000000000000', @execution_mode=0, @is_enabled=False, @policy_id=@policy_id OUTPUT, @root_condition_name=N'', @object_set=N'Simple Mode Check_ObjectSet'
Select @policy_id

GO

Now that you’ve created your policy, you can either evaluate it directly on that server or we can leverage the Central Management Server feature to evaluate this policy against one or more servers in your environment! Since we’re looking at this from an enterprise-level standpoint, we’re going to go over the CMS way of doing this.

Once you’ve established your CMS, you’re going to want to register servers to it. You could register everything directly under the CMS but then it becomes one giant list and that’s not very nice. One method I like to implement in my CMS is to create new server groups for each environment (e.g. DEV, QA, PROD). Within each group, I also create additional groupings for each version of SQL Server (e.g. 2000, 2005, 2008). Once the groups/folders have been created I then register my servers in their appropriate spots.

The advantage of breaking groups up like this is that CMS allows you to query against multiple servers at once. For instance if you were to right-click the folder for DEV, which in my case contains two registered servers in groups beneath it, SSMS will connect to both instances so that you can query them at the same time. It is this mechanism that we’ll use with Policy-Based Management since that feature allows us to evaluate policies against multiple servers in the same way.

To evaluate this policy, right-click the DEV folder and select Evaluate Policies. For source, click on the ellipses button and select either the folder location of the XML file or select the SQL Server instance which you imported the policy to. Once you’ve selected the policy’s location, you’ll see the Evaluate Policies screen with a list. Tick the box for the Simple Mode Check and then click the Evaluate button.

Check that out, you just evaluated policies against all of the databases in DEV! The databases that are NOT in simple mode (per our condition check) fail the policy evaluation and show up with red X’s. To quickly switch those to simple mode simply check the boxes for those that failed the check, then click the Apply button. This will enforce the policy on those databases and switch them for you to Simple mode! Imagine doing this that quickly and easily against hundreds of databases!

If you’re wondering if you can automate this process, the answer is absolutely! Check out the great open-source project Enterprise Policy-Management Framework over at Codeplex. This project allows you not only automate this process and policy enforcement but it also offers some really nice reporting of all this as well!

UPDATE: After chatting with Andie it looks like I forgot to mention a few things. Namely that for those wondering if this works on down-level servers (2000, 2005, etc.) the answer is YES! So long as you have a SQL Server 2008 server acting as your CMS, you can evaluate (certain) policies against down-level servers. Given this confusion I’ll write up a post on how all this works and what the caveats are.

The other point to make is that CMS uses Windows authentication only. If you have multiple domains, and there is no trust established between the domains, then this solution won’t work. If you DO have multiple domains and trust established, so long as your credentials allow you to traverse domains and the proper security authorizations are in place on the target SQL Servers then it will work.

Whether you know it or not, Policy-Based Management is an integral part of the new release of SQL Server “Denali”. Did you know that the HADR feature actually leverages PBM for checks? Yup, that’s right folks. If you’re an administrator and you’re NOT using Policy-Based Management yet, I highly recommend you pick up a book and check it out!

So what’s new in SQL Server “Denali” CTP3 for Policy-Based Management? I just got the shrink wrap off of it (I’m not quite the go-getter that Aaron Nelson is) but at a quick glance here’s the changes I see. These comparisons were made with listing of facets between SQL Server 2008 R2 and the new “Denali” CTP3 release.

We now have 84 facets (as opposed to 76 in 2008 R2). These are our new facets and their applicable target types!

Again, this still has that new install smell so I haven’t had time to mess around with it but I’ll soon be posting some new policies using these facets so you can get an idea of what you can do administratively using Policy-Based Management and these new facets.

This post is based on an interesting question/situation that was posted over at ASKSSC.com today. The user asked how to create a policy condition that enforces local sql accounts to adhere to password expiration policies.

First off, to create the condition itself is relatively easy. Below I’ve provided the T-SQL code so that you can create the condition that way. I’ve also included a quick list on how to create it via SSMS GUI.

T-SQL method:

Declare @condition_id int
EXEC msdb.dbo.sp_syspolicy_add_condition
    @name=N'Password Policy Enforced', @description=N'', @facet=N'Login',
    @expression=N'<Operator>
  <TypeClass>Bool</TypeClass>
  <OpType>AND</OpType>
  <Count>2</Count>
  <Operator>
    <TypeClass>Bool</TypeClass>
    <OpType>EQ</OpType>
    <Count>2</Count>
    <Attribute>
      <TypeClass>Bool</TypeClass>
      <Name>PasswordExpirationEnabled</Name>
    </Attribute>
    <Function>
      <TypeClass>Bool</TypeClass>
      <FunctionType>True</FunctionType>
      <ReturnType>Bool</ReturnType>
      <Count>0</Count>
    </Function>
  </Operator>
  <Operator>
    <TypeClass>Bool</TypeClass>
    <OpType>EQ</OpType>
    <Count>2</Count>
    <Attribute>
      <TypeClass>Bool</TypeClass>
      <Name>PasswordPolicyEnforced</Name>
    </Attribute>
    <Function>
      <TypeClass>Bool</TypeClass>
      <FunctionType>True</FunctionType>
      <ReturnType>Bool</ReturnType>
      <Count>0</Count>
    </Function>
  </Operator>
</Operator>', @is_name_condition=0, @obj_name=N'',
@condition_id=@condition_id OUTPUT

Select @condition_id

GO

SSMS method:

1. Under PBM node, right-click conditions folder and select New Condition
2. Name your new condition something useful
3. Select Login facet from drop-down menu
4. Click on field box and select @PasswordExpirationEnabled from properties list
5. Set the operator value to True
6. Click on ‘Click here to add clause’ to add another clause to policy
7. Click on field box and select @PasswordPolicyEnforced from properties list
8. Set the operator value to True
9. Click OK. You’ve now just created a new condition!

Now we’re left with another question: Where does this password policy come from? For details on that you can refer to the Books Online article about it (link). If your box is on a domain that has Active Directory policies regarding password expiration, when you select the box for ‘Enforce password policy’ as well as ‘Enforce password expiration’, these settings will come from that policy. Don’t have an Active Directory policy? No problem! If a policy isn’t provided from Active Directory, Windows then looks to its local security policies for these values.

To see the local values, click on your Start button, then type in ‘secpol.msc’ (don’t type type the single-quotes). This will open up the Local Security Policy MMC Snap-in. Expand the Account Policies folder and then click on the Password Policy folder. In the right side pane you will see the various password-related options you can set such as Maximum password age or password length.

While policy-based management can help you check whether or not the accounts have the option enabled to enforce the policy checks, Policy-based management itself has not bearing on the Local Security Policy settings. This is something you, as an administrator, will have to set and configure outside of SQL Server.

This is just a quick post in regards to a conversation I just had via Twitter. If you don’t already use Twitter, the SQL Community has setup a great resource on there using the hashtag of #sqlhelp.

Today a conversation came up due to a forum question over at SQLServerCentral regarding applying policies to databases with tables that have heaps. If you’re not familiar with the term, a heap is a table that has no clustered index on it. This can be problematic from a performance stand point so it might benefit you to find a way to identify these potential problem children. Enter Policy-Based Management.

This is a simple policy that you can run against your servers and it will identify your tables that are heaps. Just to clarify this policy identifies if your table has a clustered index on it. If it doesn’t then it will fail policy check. I’ve provided two ways to get the policy.

Download policy by clicking here

OR (Updated 4/15/11 to include creation script for condition)

--CREATE CONDITION

Declare @condition_id intEXEC msdb.dbo.sp_syspolicy_add_condition @name=N'Find heaps', @description=N'', @facet=N'Table', @expression=N'<Operator>  <TypeClass>Bool</TypeClass>  <OpType>EQ</OpType>  <Count>2</Count>  <Attribute>    <TypeClass>Bool</TypeClass>    <Name>HasClusteredIndex</Name>  </Attribute>  <Function>    <TypeClass>Bool</TypeClass>    <FunctionType>True</FunctionType>    <ReturnType>Bool</ReturnType>    <Count>0</Count>  </Function></Operator>', @is_name_condition=0, @obj_name=N'', @condition_id=@condition_id OUTPUTSelect @condition_id
GO

--CREATE POLICY
Declare @object_set_id int
EXEC msdb.dbo.sp_syspolicy_add_object_set @object_set_name=N'Find Table Heaps_ObjectSet', @facet=N'Table', @object_set_id=@object_set_id OUTPUT
Select @object_set_id

Declare @target_set_id int
EXEC msdb.dbo.sp_syspolicy_add_target_set @object_set_name=N'Find Table Heaps_ObjectSet', @type_skeleton=N'Server/Database/Table', @type=N'TABLE', @enabled=True, @target_set_id=@target_set_id OUTPUT
Select @target_set_id

EXEC msdb.dbo.sp_syspolicy_add_target_set_level @target_set_id=@target_set_id, @type_skeleton=N'Server/Database/Table', @level_name=N'Table', @condition_name=N'', @target_set_level_id=0
EXEC msdb.dbo.sp_syspolicy_add_target_set_level @target_set_id=@target_set_id, @type_skeleton=N'Server/Database', @level_name=N'Database', @condition_name=N'', @target_set_level_id=0

GO

Declare @policy_id int
EXEC msdb.dbo.sp_syspolicy_add_policy @name=N'Find Table Heaps', @condition_name=N'Find heaps', @policy_category=N'', @description=N'Heaps are tables without clustered indexes. Read the link below to learn more about heaps.', @help_text=N'Fragmentation (part 4):what are heaps? by Paul Randal', @help_link=N'http://blogs.msdn.com/b/sqlserverstorageengine/archive/2006/09/19/761437.aspx', @schedule_uid=N'00000000-0000-0000-0000-000000000000', @execution_mode=0, @is_enabled=False, @policy_id=@policy_id OUTPUT, @root_condition_name=N'', @object_set=N'Find Table Heaps_ObjectSet'
Select @policy_id

GO

During my presentation at SQLSaturday 62 in Tampa I was asked by an attendee about having a policy to check the setting for ad-hoc optimization settings. At the time since I was in a bit of a time crunch (and I couldn’t remember the exact facet to look under) I couldn’t properly demo how to check for it. In this post I’ll show you how to check for that specific setting. In a future post I’ll show you how to check on many more settings.

Before we begin, I highly recommend you familiarize yourself with what exactly this setting changes and how it affects your SQL Server environment. Remember this setting affects the entire instance so all databases installed here will be affected by this change. Read this great post by Bob Pusateri (Blog | Twitter) to get an understanding of what Optimizing for Ad Hoc Workloads really does.

Creating the Policy/Condition

• In SQL Server Management Studio browse down to and expand your management node, expand the Policy-Based Management node, right-click the Policies folder and select New Policy.
• Name your new policy and then from the Check Conditions drop down menu select New Condition.
• Give your new condition a name and from the Facet drop down menu select the Server Configuration facet.
• In the Expression editor, click the area below the column title of field and you will be presented with a drop-down of all the properties available for this facet. Select @OptimizeAdhocWorkloads.

Creating our new condition

• Under the heading of Value, you will have two options: True or False. When you create a policy you want to establish a condition you want so for the purposes of this demonstration we want our servers to have this setting set to off (which is default setting) so we’ll select the option for FALSE. Click OK to create your condition and return to the new policy window.
• Next we’ll select our Evaluation Mode. This policy, based on the facets and properties we’ve selected offer us three options: On demand, on schedule and On Change: log only. The last option, if enabled, will allow this policy to be active and log any changes made to this particular setting. One cool thing you can do with this is you can create alerts to automatically email you if this particular condition is violated. Check out Ken Simmons (Blog | Twitter) article on Configuring Alerts for Policy-Based Management to learn more. Leave the Evaluation Mode to On Demand and click OK.

Now that we have our policy created simply right-click on it (located under your Policies folder) and select Evaluate to try it out!

GUI? We Don’t Need No Stinking GUI!

In this post I walked you through how to create this policy using the GUI but if you prefer to script this out, you can do that too! Here is the T-SQL script that you can run in lieu of walking through the SSMS screens, to create this particular policy:

Declare @object_set_id int
EXEC msdb.dbo.sp_syspolicy_add_object_set @object_set_name=N'Ad-hoc Workload Check_ObjectSet', @facet=N'IServerConfigurationFacet', @object_set_id=@object_set_id OUTPUT
Select @object_set_id

Declare @target_set_id int
EXEC msdb.dbo.sp_syspolicy_add_target_set @object_set_name=N'Ad-hoc Workload Check_ObjectSet', @type_skeleton=N'Server', @type=N'SERVER', @enabled=True, @target_set_id=@target_set_id OUTPUT
Select @target_set_id
GO

Declare @policy_id int
EXEC msdb.dbo.sp_syspolicy_add_policy @name=N'Ad-hoc Workload Check', @condition_name=N'adhoc optimization check', @policy_category=N'', @description=N'This policy checks the server setting to see if Optimize for Ad-Hoc Workload is enabled. The default setting is disabled.', @help_text=N'To learn more about this policy check out Jorge Segarra''s blog post on this', @help_link=N'http://sqlchicken.com/2011/01/policy-for-ad-hoc-workloads/', @schedule_uid=N'00000000-0000-0000-0000-000000000000', @execution_mode=0, @is_enabled=False, @policy_id=@policy_id OUTPUT, @root_condition_name=N'', @object_set=N'Ad-hoc Workload Check_ObjectSet'
Select @policy_id
GO

Conclusion

Again, I can’t iterate enough NOT to blindly go changing settings on your servers without understanding the effects of your actions! Policy-Based Management is a very powerful and easy-to-use tool but be sure to use it wisely! In a later post I will show you how to modify even more server-level settings and let you customize policies to check exactly the settings you want audit.

This is just a quick note to remind everyone I’ll be presenting tomorrow, Tuesday October 26th 2010 for the PragmaticWorks Free Monthly Webinar Series. The topic (big surprise here) is Policy-Based Management!

The webinar runs from 11:00 AM – 12:00 PM EDT and you can register for free here. Hope to see you all there!

Just a quick note that today at 12:30 EST (11:30 CST) I’ll be presenting on Policy-Based Management for SQLLunch. If you’re not familiar with SQLLunch it’s an awesome series of FREE webcasts setup by SQL MVP Patrick LeBlanc (Blog | Twitter). Each webcast focuses on a different aspect of SQL Server.

Free training? Can’t beat it, make sure to check it out! To find out latest news on SQLLunch and all upcoming webcasts register on their site for free. You can also join PASS (free) directly from their registration, Win/Win!

Info on today’s webcast:

SQLLunch #29: Policy-Based Management

Topic: #29-Policy-Based Management in a Nutshell
We will be learning an overview of this powerful new feature in SQL Server 2008 and how you can leverage it to help manage your existing SQL environment. This will include plenty of demos, best practices and Q&A so by the end you should be able to walk away ready to take control of your SQL Servers!

Hope to see you there!

After months of deadlines, late night writing sessions, getting my ass handed to me by ADD and editors, and a loving wife pushing me to write some more the book is now done! A HUGE thank you to Ken Simmons for inviting Colin Stasiuk and myself to be a part of this project. Also huge thanks to all the folks at Apress for doing a great job pushing this along as well as Tom LaRock, whose technical editing on this book was a great asset. According to Amazon, the book should be available April 27th so make sure you buy plenty of copies for you and your loved ones. After all, nothing says “I love you” like the gift of policies that stop developers from horrendous naming conventions Policy-Based Management. You can also get the book directly from Apress by going to http://www.policybasedmanagement.com.