Database servers worry me—in particular, the "uninvited" ones, the "unknown" ones, the unpatched ones. The worm food.
A few years ago, the Microsoft Windows 2000 Resource Kit introduced a neat little utility that answered a question I've heard many times from ex-Novell administrators: "How can I stop concurrent logons? That is, how can I ensure that users can be logged on to the domain from just one machine at a time?" Called Cconnect, this utility seemed promising—until I realized that it requires Microsoft SQL Server to operate.
"Ugh," I said to myself, "I don't want to learn any new administration responsibilities."
But that was just the beginning. Later, Microsoft came out with Ultrasound, a cool free tool for monitoring Sysvol folders on domain controllers (DCs). I often find Sysvol folders to be troublesome, so I resolved to download Ultrasound and play with it. But one look at the README file showed that Ultrasound needed SQL Server to run. Bummer.
Then, the Application Compatibility Toolkit (ACT) 4.0 came out. I liked the previous ACTs because they solved a lot of problems involving applications that worked under Windows NT 4.0 or Windows 98 but failed to work under later OSs. But ACT required—gasp—SQL Server. "Oh well," I murmured, recognizing the growing resignation in my voice.
Only a few months later, Microsoft delivered the deathblow to my SQL Server aversion. Of course, I'm speaking of Windows Software Update Services (WSUS), the all-in-one-place patch repository for Windows, Office, Exchange Server, and more. WSUS is the nifty successor of one of my favorite free Microsoft tools, Software Update Services (SUS). And WSUS absolutely requires—you guessed it—a running SQL Server instance.
Okay, I surrender.
I'm exaggerating about my SQL Server predicament. I've run SQL Server for years and have written a few Web-based applications that depend on it. Besides, managing SQL Server isn't all that hard if you have the full-blown copy of SQL Server 2000, which comes with a nice GUI-based administration tool called Enterprise Manager. However, I frequently advise people on using nifty free Microsoft utilities such as Cconnect, Ultrasound, ACT 4.0, and WSUS, and I don't like informing people that they have to set up a big new system to take advantage of those tools.
What troubles me is that most folks who simply want to try one of those free utilities aren't going to shell out the necessary cash for a copy of SQL Server 2000. Of course, Microsoft doesn't expect them to do that: In addition to offering the free utilities, the company also offers a free version of SQL Server 2000 called the Microsoft SQL Server Desktop Engine (MSDE), which has essentially the same core engine as SQL Server 2000 but lacks Enterprise Manager. That's an understandable exclusion—the tool is free, after all—but it's still disappointing.
I suspect that, in the next year or so, many administrators will start implementing WSUS on their systems. The WSUS installation comes with a version of MSDE called WMSDE. In fact, if you don't pay close attention while installing WSUS, you might not even notice that you suddenly have SQL Server running on your WSUS machine. Therein lies the problem, as I see it.
For years, applications such as Veritas' Backup Exec have come packaged with MSDE, installing the database server without really considering the consequences of doing so. MSDE is a fine tool, particularly considering the price tag, but like any other big subsystem, it needs at least a little attention. Why? Because in the past, we've seen a few nasty worms that have exploited bugs in SQL Server 2000. Now, as far as I can see, an up-to-date, patched MSDE system isn't a danger to your network or the Internet. But what happens if Microsoft discovers some new MSDE vulnerability and releases a patch for it? Everyone running MSDE would need to obtain and install those patches. But, again, if you don't know you're running an MSDE service, you won't watch for the patches.
The bad guys know we're going to see huge growth in the number of MSDE boxes running in the next year or so, and believe me, if a SQL Server vulnerability appears, they'll be on it in a flash. And you don't want to become a victim of SQL Server exploitation, right?
I know what you're saying. You're saying, "Hey, Mark, you forgot that you've just set up a WSUS server. Because WSUS handles SQL Server patches in addition to Windows, Exchange, Office, and the rest, any MSDE boxes in the house will be properly patched." Ah, I wish it were true, friends. But as far as I can see, WSUS doesn't currently handle SQL Server patches. Maybe the next version.
So here are a few suggestions.
1) Find out if you're running any instances of SQL Server, whether they're the kind that came at a cost or the free MSDE instances that might have slipped in under your radar. On your servers and developer workstations, search the Microsoft Management Console (MMC) Services snap-in for the MSSQLServer service. You'll see it for either SQL Server or MSDE. And remember that it's possible to run more than one copy of SQL Server or MSDE on your system, so don't be surprised if you see MSSQLServer with some appended text (e.g., MSSQLServer$Server2).
2) Make sure those SQL Server instances are patched. You can apply SQL Server 2000 Service Pack 4 (SP4) to SQL Server 2000 or MSDE. (If you have WSUS, the accompanying WMSDE is already patched.) Install SQL Server 2000 SP4 on the system, and you'll be up-to-date. But check Microsoft's site the second Tuesday of every month, just in case some other patches appear.
3) Get yourself a free Enterprise Manager alternative. You can install the free tool Web Data Administrator on Microsoft IIS 5.0 or later to administer MSDE with a nice GUI. Search the Microsoft site for "SQL Web Data Administrator" to find it. The tool is still a bit rough-edged, but with some work you can get it running.
4) Start reading up on MSDE administration. Microsoft has a few helpful articles on the topic, and I've written a few things. Indeed, as you'd imagine, entire Web sites are devoted to SQL Server administration.
So, don't be afraid of running a database server, even if it's MSDE. Just stay on top of the patches and be aware of where your servers are. When the next database worm appears, you'll be able to just sit back, smile, and pity the poor folks running around trying to find all their database "worm farms."
