Why isn’t SQL Server included in Windows Critical Update notifications? Many of our readers noted that they are part-time DBAs and simply don’t have the time to stay up-to-date on what patches and service packs should be applied to all the software that runs on their servers. What are the technical and practical implications of including SQL Server in Windows Critical Updates, and are there plans to do so?

The Microsoft Trustworthy Computing team, led by Mike Nash, has patch management as a top priority. WU is a great method for Windows, but there may be better ways to deliver updates for multiple products. The Trustworthy Computing team is looking at the best way to implement updates through a single system.

We certainly want to give customers more-effective tools to monitor and lock down their servers from a security perspective. We see the latest version of the tools we released as part of our SQL Critical Update Kit to be a first step toward achieving this goal. Currently, we’re gathering customer feedback about how we can improve these tools going forward and plan to add functionality to these tools to make them as effective as possible.

Part of this process is also education, and we’re updating existing white papers to focus more on security best practices. We’ll also continue to invest in and grow MBSA to include more SQL Server-specific vulnerability checks.

How does MBSA and the SQL Critical Update Kit tools work together?

We recommend running MBSA 1.1 to analyze potential vulnerabilities in your systems, then use SQL Scan to look for the particular vulnerabilities inside your environment. Version 1.1 is the second release of MBSA and includes a graphical and a command-line interface that can perform local or remote scans of Windows systems. MBSA runs on Windows 2000 and Windows XP systems and will scan for common system misconfigurations and missing security updates in SQL Server 2000 and 7.0 and other Microsoft products. If MBSA finds a vulnerability, it points you to the proper patch to download. In contrast, the SQL Update tools actually go and apply the patch that protects against Slammer. Customers interested in finding out more about MBSA can visit http://www.microsoft.com/technet/security/tools/tools/mbsahome.asp.

We developed the SQL Critical Update Kit tools because we needed to quickly develop specific tools to help SQL Server customers understand what’s going on in their environment. But as I noted earlier, our long-term goal is to bring all these tools together under the MBSA umbrella and offer customers a single tool that scans for all products in their infrastructure.

Slammer affected a large number of MSDE installations. How can Microsoft help people stay up-to-date with patches when many applications install MSDE by default and administrators might not even be aware that MSDE is on the box? What has Slammer taught Microsoft about the advisability of installing a product like MSDE by default without notification?

We’re working on a more simple patch application specifically for MSDE that would let users patch MSDE from a GUI application. We still believe that MSDE is important as a light data store, and we’ll continue to make it better, more secure, and easier to patch and administer.

As I mentioned earlier, we’re looking to improve our SQL Scan and SQL Check tools as well as other tools to detect SQL Server instances including MSDE. We’re also working closely with MSDE partners to ensure that they follow recommended procedures of minimalist installation and secure defaults and to make sure that MSDE is installed only when absolutely needed and through customer choice. In addition, we’re working to better document applications that install MSDE and working to better highlight in those applications’ documentation that they install MSDE. Our goal is to be very explicit with the installation of MSDE going forward, not only in posting on our Web site which applications use MSDE but making end users aware that they are about to install MSDE as part of their application.

Prev. page     1 2 [3] 4 5     next page



You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

Here's another reason why SQL Server support staffs don't immediately apply service packs. Just because a service pack is available doesn't mean that it is completely tested and error free for your systems. We have a server that we just applied SP3 on last week. Immediately after the upgrade, we found applications that used to run in 2 minutes running over 55 minutes. After running and re-running sp_updatestats, we had no improvement. fter running Update Statistics TABLE with fullscan (a supposed solution if the SP_updatestats doesn't help), we again had no improvement. After studying all other possible causes, including memory settings, we could find no solution. I finally uninstalled SQL Server 2000 with SP3 (sure would be nice to have an uninstall) and then re-installed with SP2--the problem immediately went away, and we had our 2 minute response time. Now, you might say we could tune our applications and add indexes to solve this. Probably true. However, when I upgrade the server to the new and improved service pack, I shouldn't have to retune the performance of software that we have installed at 100+ customer sites. Therefore, you can see why a DBA might be reluctant to start running new service packs when they are announced as available. Beta testing service packs is not a cost-efficient endeavor.

Thanks..Ted Henderson

Ted Henderson- April 28, 2003

The ongoing emphasis by Microsoft on not using mixed mode authentication is particularly frustrating. Microsoft needs to do a better job of motivating 3rd party software vendors to support Windows authentication. NOt only don't they support it now, but when you ask when they will your question is met with silence. They have no plans to move to it. It is these vendors that make the decision for us. We have no discretion in choosing our authentication mode! Kay

Kay Conheady- May 01, 2003

To the question of why DBAs didn’t apply the patch Mr. Mangione responds, “The key will be to make these patches easier for customers to understand and deploy..." But problem is that Microsoft is becoming a victim of its our own “ease of use” success. So I was very disappointed to hear this response.

Lets be honest, “ease of use” is a double edged sword. On one side we have a product that should take care of mundane tasks BUT on the other it can dumb down a shop, lower everyone’s salaries, and ends up causing a downward spiral (dumb people doing dumb things requiring even more “ease of use”) eventually leading customers to dump SQL Server for more robust products (products that require skilled keepers). I have experience seeing this happen. Its to the point where many IT managers consider SQL Server DBAs to be mere babysitters preferring Oracle DBAs for the “real” work. And I was even been told by a MS SQL Server evangelist that for enterprise class shops they would recommend hiring Oracle DBAs.

IT shops are not hiring qualified people for MS products because MS pitches the idea that its products are self-maintaining and requires only semi-skilled labor (read as lower wages/cost). I would really like to see an honest discussion about if this minimally qualified work force is where we want to take things or not. I think if this trend continues the creative people in this field will leave perhaps for other careers or other platforms. And if we don’t want to be replaced by monkeys or robots, having all our salaries lowered to minimum wage, and work in dreadfully boring spaces with dreadfully boring people then how can we improve SQL DBA training/certification? Currently, the training and cert programs are not well respected nor do they adequately prepare one for being a DBA/database developer. BUT I don’t see anyone talking about this issue! At least not in this magazine.

Mike- May 01, 2003

 
 

ADS BY GOOGLE