This week I have spent a lot of time installing and playing with the new CTP. The installation process is as easy as it is for SQL 2008, I must have installed this CTP 25 times at least and did not have one problem. I was most interested in the Multi-Server features especially the Utility Control Point Server and I am very impressed with it. The dashboard view is especially impressive in its ease of use. I did run into a few surprises that took me longer than it should to figure out. 

I have been setting up policies on my 2008 servers. I thought a good place to start would be with the suggested policies Microsoft provides with their samples. You can download the sample databases from codeplex.

I came across a sample policy named “Public Not Granted Server Permission”, now this sounds like something a person would want to implement. I imported the policy and ran it on my test system and discovered my system failed, but I was not really sure why. The policy explains that the server role public has been granted server level permissions. OK, but what does that mean? What server level permissions? This policy does not provide an option to force compliance, so the dba must correct the issue manually, but how and if you correct what permissions will be revoked?

 On Thursday June 11th from noon to 1pm I will be speaking at the Louisville PASS chapter meeting.   The meeting is being held at Kindred Healthcare, 680 S. Fourth Street.  The topic is "Defensive SQL Server Security."  I believe that Idera will be providing Pizza.  I hope to see some of you there

I am not sure if it is a symptom of my advanced age, but I am forgetting more and more.  I know that you can't do an inplace upgrade from a 32-bit version of SQL 2005 to a 64-bit version, but I did indeed forget.   I am running into this issue more frequently on SQL 2008 upgrades than I did with previous version, becuase SQL 2008 offers Workgroup Edition 64-bit for the first time.  Many of the customers running Workgroup Edition SQL 2005 in a WOW configuration are looking to upgrade.    

  Johnny has been on vacation this week ( I hope he is having a good time, because he will never get to go on another one ever again, he does too much around here)  and I have been covering much of his responbilities.  Configuring SQL Server instances, fixing failed jobs, answering support questions, etc, etc.    I will be honest, I do not much of this work any more.

 In my ongoing effort to automate everything.  I wanted to have a script that would change the default number of error logs.   Aftersome looking around in help and on the internets, I realized I was going to have come up with a solution on my own.   I was complaining to Ryan about having to do some real work,  when he suggested that I just run a trace when  I make the change via Management Studio.

Warning:  This post involves the death a dog, if you are sensitve.   

Brent Ozar is hosting a webcast today about disaster recovery horror stories and I thought back to my “favorite” horror story and how much I have learned since then.  I have been working with SQL Server since 1997, but I was not a real dba until I took a job at large insurance company in 2000.  At that time, a lot of large companies only trusted SQL Server to be the back end to their websites, but did not trust it to run their actual business.