OnQ

On Misteaks

It's just one of those things, I guess, but when it causes so much pain, it's hard to see it as a little thing. I mean, come one, everyone makes little mistakes occasionally, don't they? I do, I own up to it when I do, also. And I've made some doozies in my day, too. But the mistakes I've made, including the big ones, have only impacted a small number of people.

But occasionally, there's the little slipup with the big impact. Yesterday saw another one of those, and while I was tangentially impacted, it really didn't hit me personally very hard. But those it did hit, it hit hard. You see, because of a mixup in a virus scanning search string, the product from a certain anti-virus vendor started identifying a core Windows system file as infected and quarrantined the file. Oops.

Now don't get me wrong, I admire anti-virus vendors and the work that they do. They often times have a thankless job. It's amazing that they are able to create search strings for virus program patterns that will really only find the virus code in a file and not (usually) mis-identify a regular, uninfected program as a problem. Given all the different programs and files that can be present on any given computer at any given time, it's amazing that there aren't more false positives than there are.

Still, this is one that really should have been caught before it got out the door. I would think that if you are testing updates to a program, one of the basic things you would check is to make sure that it didn't break the OS it was running on. I have not done much software development recently, but back in the day, I wrote code for a Linux-based system, and we used a few scripts to configure certain file areas on the system. One of the first things I tested was to make sure the file system changes we made wouldn't render the system unbootable. Seems fairly basic to me. And maybe this company did do some level of testing, but somehow it still strikes me as odd that this wouldn't have been found in a thorough testing environment.

And this is not the only company that has released software that rendered systems unbootable. At least one other anti-virus vendor released a virus engine update that wreaked havoc. An uninterruptible power supply vendor had a program that, when not updated in a timely fashion, would keep a system from booting normally. And a certain operating system supplier has been guilty of releasing updates to its own code that had drastic unexpected results. It happens. Really, it does, and fortunately it doesn't happen more often than we see it happen.

Let me wrap up by saying that I'm really glad that this particular situation didn't happen close to Patch Tuesday. I can only imagine what would have happened if people went to install updates, rebooted, and found that their systems didn't come back up. The Microsoft phone lines would have been ringing off the hook, and a lot of people would have been chasing down the wrong road. This is actually a perfect example of why I always restart a server before installing security updates. If there's a problem with the server coming up before installing the updates, there very likely would have been problems with it coming up after the updates installed. And where would I have focused my ire, I mean, troubleshooting efforts? Right, at Microsoft. It would be easy to blame the patches for causing the no boot situation. If this had happened a couple of weeks ago, MS would have been crucified by thousands of callers blaming the security updates, and lots of time and energy would have been wasted looking in the wrong place for the cause.

Just goes to show that you should take any server reboot seriously. I always make sure that, before I reboot any server (mine or a client's) that I have the time to go onsite if a problem should present itself. It's very easy to become lax towards server reboots because, most of the time, they work exactly as they should. But in the case of some people yesterday who rebooted with their guard down, they had a bit of a rude awakening. Hopefully, the worst is over for now for this particular incident. Who knows where the next one will come from...

Friends Don't Let Friends Buy OEM

I'm breaking from my normal post titling because I really want this to stand out. I've long been opposed to purchasing OEM SBS with a new server, for the usual reasons - cant' move it to new hardware, going to wipe the factory install and do it right anyway, etc., etc., etc. Well, today I ran across another reason not to go OEM, and, of couse, it's because of a Mac issue:

Entourage.

Susan Bradley has put up several posts in her blog about the difficulty we've seen in the SBS community with getting our hands on the Entourage installer media if we're not purchasing an Open LIcesnse media kit for SBS. I've been doing Open LIcense media for most of my installs to make sure that I get the Entourage install media, but also because I'm just that way. Retail media does not include the Entourage installer, but you can acquire the media directly from Microsoft, at least according to Susan. I've honestly not tried, but I've not had a situation where I've needed to try.

Until recentely.

An associate of mine recently asked me about how to get the Entourage installer for one of his clients, and I pointed him back to Susan's blog. He called to order the part, but was told that since he got OEM media with the server, he would have to go back to his OEM provider to get the media. That OEM provider, yes I'm naming names, is Dell.

This afternoon, I got a call from my new Dell software sales guy (I've been fortunate enough to have the same hardware sales rep for almost two years) who wanted to introduce himself to me. What better way to break him in than to dump this in his lap?

So I explained the situation to him so he could understand what was going on, and he immediately escalated within his team (not surprising and not a problem for me - I fully expected this). He actually got his escalation counterpart on the phone and I went through the explanation again, this time providing them with the MS part number for the retail Entourage CD media so they could look it up.

After a brief delay, I was informed that Dell does not provide a media set with an Entourage installer for their SBS OEM installs.

I've already started a query within my MS channels on this, but I've found yet another reason I will never, ever, purchase a new server for myself or for a client with an OEM installation. This just moved from the category of "well, I'll very likely never do this" to "if hell hasn't frozen over."

Updates as they become available...

On MSDE

Installing named MSDE instances on a server is a pretty common thing. Or so i thought until I ran into two applications that have given me fits. I mean, it's been a long time since I've been a programmer (well, at least a paid one), but seriously, it's not that hard to figure out how to install a named MSDE instance so that it doesn't conflict with another database already on the box.

Right?

Apparently not. One vendor has an installer that simply dies if any other MSDE databases are installed on the box. The installer assumes that there are no other instances (or will be no other instances) so it only checks to see if some of the key components are installed on the box and then aborts the install if they are. Geez! You've never, EVER, had a client want to install your product on a box where another database lives? And you've been in business how long? And you call this version 7?

Only slightly less excusable is a second vendor who, until recently, played well with others. I've done a couple dozen installs of their product on SBS servers (raise your hand if you know how many MSDE databases SBS installs by default - hint: it's more than one) with no issues, but they updated their installer and now it apparently fails to recognize which MSDE slot to try and install into. They've at least got a workaround, but good grief, what happened to quality control and testing?

So to all you database developers out there, please, please, please, please figure out how to correctly install a named instance of your MSDE database on a server, even if there are no other MSDE instances present. It's very short-sighted to assume that you're producing the only MSDE database in the world and can short-cut the detection process during an installation. Your customers and your partners will be very, very happy.