• Categories

  • Recent Posts

  • Archives

  • Copyright Notice

    Copyright © Nancy Hidy Wilson, 2010-2013. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Nancy Hidy Wilson and nancyhidywilson.wordpress.com with appropriate and specific direction to the original content.

SQLSaturday #461 Austin 2016 – I’m Presenting

I will be presenting my SQL Server Deprecated and Discontinued Features session at SQLSaturday #461 in Austin on January 30th. If you have older versions of SQL Server which need to be upgraded to one of the more recent versions, come to my session to find out how to detect potential issues, what you need to fix before upgrading\migrating, and what you’ll need to fix after upgrading\migrating.

Check out the entire schedule here. There are sessions for SQL Developers, DBAs, Business Intelligence folks, and even a couple of Professional Development sessions. And, in case you are unfamiliar with SQLSaturday – it is FREE day of training thanks to these generous sponsors.

I’m looking forward to seeing my Austin #SQLFamily – Jim Murphy, Wes Brown, John Sterrett, and you! Register here!

 

Advertisements

SQLSaturday #447 Dallas – I am Speaking

SQLSat_logoThe first SQLSaturday I ever attended was #35 in Dallas and the North Texas SQL Server User Group (NTSSUG) set the bar high as host. That was several years ago and scheduling conflicts have prevented me from making the drive up I-45 from Houston to attend another SQLSaturday there. However, this year, I’m honored to be presenting at SQLSaturday #447 Dallas on October 3, 2015. My topic is “Managing SQL Server in the Enterprise with TLAs”.  What are TLAs, you ask? Why Three-Letter-Acronyms, of course! The TLAs that I will be discussing which you as a SQL Server DBA should be utilizing are CMS, PBM, and EPM. Come to my session in Room 100 at 8:30am (updated 9/30 for schedule change) and find out how using these features will improve your productivity and help you ensure standards are being followed in your environment.

If you are a data professional within driving distance of the DFW Metroplex, you should consider attending this free day of learning at the University of Texas at Arlington (UTA) hosted by the North Texas SQL Server User Group.

Check out the entire schedule, including low-priced Pre-con sessions on Friday, and register today to take advantage of this free training!

If you can’t attend this event, then check here for all the currently scheduled SQLSaturdays in the US and around the world! There is likely one occurring near you soon!

Learn Something New (or Old) Every Day

I’m a big proponent of constant learning – looking to learn something new every day. It doesn’t have to be some big revelation. Sometimes it is just a tip on how to do something more efficiently (like in PowerShell) and sometimes it isn’t even new!

Recently, I was in a discussion about proposing a best practice recommendation in the CIS SQL Benchmarks to ensure deleted Active Directory Windows logins are also removed from all SQL Server instances where they were granted a login. One of the team members did a little research and found a reference to a system stored procedure which might help – sys.sp_validatelogins. My first question was – is it a documented procedure? Microsoft warns against using undocumented commands as they could get changed with most any update. Yes, it is officially documented in BOL (2008+). Second question – since which SQL Server version? Since at least SQL 2000 per this BOL! I have to confess, as many years and versions that I’ve been working with SQL Server and researching various security aspects, I was surprised that I didn’t recall this procedure – especially when the first non-BOL reference that I found in my own search turned up an article written by my friend Tim Ford for MSSQLTips!

In large, complex environments, both the processes (coordination between teams with varying responsibilities) and the technical aspects (how to identify these logins) can be, well, complex! But, depending upon your AD structure and the trusts in place, you as a DBA could periodically run this system stored procedure on your instances to find Windows logins or groups which are SQL Server logins but no longer exist in AD. You can then do a more thorough search of the specific instance’s databases and remove the login from all databases where it is a user, ensure that it isn’t a database owner, and ultimately remove the login from the instance. There is no currently known security risk to leave these orphaned logins on your SQL Server, but just like cleaning up orphaned users in your databases which do not have a specific instance login, it is considered a best practice to perform this task. And, for those of us who are neat freaks – it just makes your instance “cleaner” to get rid of the clutter of obsolete logins!

While it would be tempting to automate this check and just drop the database users, then drop the login, I did find that Thomas LaRock documented an anomaly he found several years ago which would make me always want to manually double-check the AD for any accounts reported as orphaned to ensure the account is really no longer valid. But at least you have narrowed down the search by using this procedure.

So, when looking to learn something new – don’t forget sometimes what you may learn is old – both Tim’s and Tom’s blogs were from 2009!

TSQL2sday #70 – Strategies for Managing an Enterprise

tsql2sday

Jen McCown (Twitter) of Midnight DBA is the guest host for this month’s SQL blogger event known as T-SQL Tuesday (#TSQL2sday) which was started almost 6 years ago by Adam Machanic. This month, Jen has assigned us the topic: Strategies for Managing an Enterprise. Jen will be doing a wrap-up summary of all blog posts submitted on this topic per the rules and I’m looking forward to everyone’s input on this subject.

I’ve been presenting a session for the past several years at SQLSaturday events entitled “Managing SQL Server in the Enterprise with TLAs”. The TLAs (three-letter acronyms) are CMS (Central Management Server), PBM (Policy Based Management) and EPM (Enterprise Policy Management Framework). I’ll be presenting this session at SQLSaturday #447 Dallas on Oct. 3rd, 2015, so you can come learn the details of these features then. But, per the assigned topic for this post, let’s focus on the “strategies” driving the usage of these features.

For me, one of the main goals in managing the enterprise is finding ways to reduce the effort in managing that landscape –whether two instances of SQL Server or two thousand instances. A strategy for getting there is organization. The CMS enables you to define groups to which you register your SQL Server instances and then you can perform tasks against those groups. Why perform a task per instance when you can do it for multiple instances at one time? The CMS is actually defined in tables in the msdb database of the designated instance. I would recommend having a dedicated “central management server” instance which you will use for CMS, PBM, EPM, and other administrative tasks.

With CMS, you can create many groups and register instances in multiple groups based on the tasks that you may want to perform against those groups. For example, you can create groups to organize by SQL Server version, by Production\UA\QA\Dev\Test, by Application, by location, and be sure to have one group with all your SQL Server instances registered to it. SQL Server Management Studio (SSMS) enables you to run “multi-instance” queries using a CMS group. That is, you execute the contents of the Query window against every server instance in the specified group and the results are returned to the SSMS console.

A second strategy in managing the enterprise is standardization. Policy Based Management enables you to define expected settings (e.g. conditions) and verify whether an instance of SQL Server meets those conditions. Examples of policies could be checking that the sa login is disabled or ensuring the AUTO_SHRINK option is off on all databases. My recommendation is to configure the policies on the same instance as your CMS groups (e.g. your dedicated central management server) so that you only have to manage one set of policies. Policy definitions are also stored in the msdb database. You will also want to export the policies to a central file server. Policies are exported as XML formatted files. When evaluating the policies on a specific instance, you may use either the central management SQL Server instance or the file server where they are stored as the source. SSMS also allows you to manually evaluate policies against a CMS group – returning all the results to your SSMS console.

The third strategy is automation. If you have a CMDB (Configuration Management Database), then you can utilize it as the source for populating your CMS groups by scripting the entire process to keep your CMS groups current with the CMDB contents and setting this up as a SQLAgent job to schedule as needed. Policies can be assigned to categories. The EPM Framework provides a mechanism (a PowerShell script) to automate the PBM evaluations by category against a specific CMS group and store the results for reporting. EPM requires a database repository to store the results, so again I recommend creating this database on a dedicated central management server. Once you’ve been through the exercise of setting up your CMS, establishing policies, and configuring the EPM Framework for your environment, you’ll see additional opportunities to utilize the CMS for automating other tasks.

So, start leveraging the CMS, PBM, and EPM features today to reduce your efforts by organizing your instances, increasing standardization, and automating tasks in your enterprise!

TSQL2sday #68 – Just Say No to Defaults

T-SQL Tuesday (aka #TSQL2sday) is a monthly SQL Server blogger event started back in late 2009 by Adam Machanic (blog | twitter). For more info on its beginning and purpose see the origin of TSQL2sday. Each month a different SQL Server blogger is the host (announces the theme and compiles a recap). This month’s event is hosted by Andy Yun (blog | twitter) and the selected theme for this month is “Just Say No to Defaults”.

This is really embarrassing, but I’ve had a blog post started for this topic for years and somehow never got around to finishing it! Thanks, Andy, for giving me a reason to finally address a couple of my “must change” defaults.

Ease of installation is definitely a feature that has helped SQL Server to proliferate. You can have a functional system just by running setup and clicking Next, Next, Next….Finish! Without having to make any real decisions about what you are doing, you can be up and running in no time.

When installing the database engine component, the first change to be considered from the defaults presented during setup is the location of the various file types – however, I’m going to save that for others to address and may come back to it in a future post.

Today, I’m going to address a default that you can’t change during the setup dialog or via configuration file parameters. It must be adjusted post-install and is for SQLAgent.

Ever go to review the job history for a job and find nothing or only a couple of recent entries and you know the job has been running for weeks or even months? So, where is all that history? Sorry, you were the victim of the ridiculous defaults shown below which limit the total number of rows in the msdb.dbo.sysjobhistory table as well as set a max number of history rows per job.

To find this dialog in SSMS, right-click on SQLAgent, then select Properties, then select History.

SQLAgentHistoryProperties

These are defaults that you definitely want to change. In fact, instead of just increasing the number of maximum rows for the table and per job, I’d recommend that you decide on the time frame that you want to keep your SQLAgent job history and uncheck the “Limit size of job history log” option and check the “Remove agent history” option and specify the desired time frame instead as shown below. Many companies already have specifications for how long to retain activity logs, so using the time period that meets or exceeds those requirements should be helpful when it comes audit time.

SQLAgentHistoryProperties_ByTime

Depending on the number of jobs and the frequency at which each is run, you may also need to keep a close watch on the size of msdb after changing this setting to find the optimum size for your msdb files to allow the sysjobhistory table to grow to its expected size without causing autogrow of your files. Remember to manage msdb just like any other application database with appropriate purges, backups, and other maintenance.

I can’t wait to see what others say “no” to in Andy’s round-up for this event. I’ll be looking for my other must change items and if I don’t see them, then I will be posting more soon!

SQL Server 2012 Security Benchmark Released

The Center for Internet Security (CIS) Security Benchmarks Division released “CIS Microsoft SQL Server 2012 Database Engine Benchmark V1.0.0” on January 6, 2014. 

CIS_SQL2012_Benchmark_V1This is a consensus-based development of security best practices which have become the de facto security configuration standards.  If you are in charge of your SQL Server security configuration, you need a copy of this document – it is what your auditors will be using soon! 

I am currently serving as one of the editors for the SQL Server benchmarks. We are in progress with updating the SQL Server 2008 R2 benchmark previously released in late 2012.  If you discover any items we should update\add\delete in that document or in the newly released 2012 benchmark, please either leave a comment here on my blog or better yet join the benchmark community consensus team (http://benchmarks.cisecurity.org/community)!

SQL Server 2008 R2 Security Benchmark Released

The Center for Internet Security (CIS) Security Benchmarks Division released “CIS Microsoft SQL Server 2008 R2 Database Engine Benchmark V1.0.0” on November 16, 2012. The best I can tell, this benchmark can also be used with SQL Server 2008.

CISSQL2008R2This is a consensus-based development of security best practices which have become the de facto security configuration standards.  If you are in charge of your SQL Server security configuration, you need a copy of this document – it is what your auditors will be using soon!