Sophos is not immune, either.
Over the last couple of years, several anti-virus vendors have had some bad press related to false positives that deleted significant or important files from systems. My anti-virus vendor of choice, Sophos, has not been one of those mentioned. Until today.
Last night, I received antivirus alerts from several systems that Sophos had found and taken action on several files, most notably QuickBooks files (C:\Program Files\Intuit\QuickBooks 2009\Components\PConfig\Data1.cab, although it was the same thing for versions all the way back to 2006 as well). I had already been in the process of changing the default actions of Sophos to "quarantine" instead of "delete" but had not hit all of my systems with that update yet. I put a quick call into Sophos tech support early this morning (gotta love that 24x7 support when you need it) and found out that their update that was released last night before 9pm CST had a false positive string in it, and the scheduled scans I had set to run at 9pm on these systems used that false positive update and nuked these QB files. Sophos did report that they have already released additional updates that have alleviated the problem, but because of the timing of the updates and the timing of my scheduled scans, several of my clients have QuickBooks data files that I get to go back and restore.
In the grand scheme of things, this isn't huge (like nuking a Windows system file) but for my accounting and financial services clients, well, it's a good thing it happened on Thanksgiving morning so it will minimize the impact on their operations. We'll be able to restore the specific file from backup in most cases, and worst case do a reinstall of the app on a workstation. Much better than having to rebuild a box or reload the OS.
Over the weekend, I'll be finishing up getting my Sophos configs updated to "quarantine" and not "delete" to help protect against future false positives. Still, just goes to show, it can happen to anyone. Past history of false positives (or lack thereof) shouldn't be the only deciding factor in choosing an anti-virus solution for your business or your clients.
If the only thing I do for the community the rest of the year is to get a few more IT Professionals to not only think seriously about SBS 2008 migrations but to actually start training on the process, I'll take it. That's how important I believe it is. The SBS 2003 to SBS 2008 migration is NOT your familiar SBS 2000 to SBS 2003 Swing Migration. SBS 2008 is a completely different product, and as a result, the path to get there is completely different as well.
I started talking about the need to learn about migration back in August in a post from this blog. I mentioned it again in a guest blog I'm doing for Network World this month. Susan Bradley talked about it in a post from October 30, 2008. There have been discussions about the migration story in the SBS 2008 newsgroups and over on smallbizserver.net. Several threads about migration have cropped up in a number of SBS-related Yahoo groups.
The common theme from the folks who worked with the migration process during the SBS 2008 beta is this - learn about the migration before you do one, and start that learning process now. If you're assuming that because it's all wizardized that SBS 2008 will have any similarity to SBS 2003, that's a faulty assumption. This is a vastly differnet product, and there will be a learning curve to becoming proficient in supporting the product. That learning curve is even steeper when it comes to migration.
Please, if you haven't already, look at the SBS 2008 Migration Document from Microsoft. Keep checking the link to the Latest Version to make sure that you are working from the most recent update to the document (the development team has assured us that they will be continually updating the document as they identify issues that need to be corrected). Test the migration process against a clean, freshly-built SBS 2003 server. Test the migration process against your own server (virtually, in a lab). Test the migration process against one of your customer's servers that's a really crusty server with lots of apps installed (virtually, in a lab). Trust us, the time you figure out there's an "oops" within the process is when you're testing the process for your own training or documentation, not when you're out trying to do one of these things for a customer.