June 18, 2011 at 11:03 am
Comments posted to this topic are about the item Patch Week
June 19, 2011 at 11:33 pm
There is a HUGE difference between "few patches" and "safe". Just because there are so few patches doesnt mean alot when judging how safe a system is or how well designed it is. Thats the same comment that one see from the Mac fanatics as well. Things like "Nr of installations", "User category", "Environment" (as to how the software is installed) all effect how likely it is that someone will put alot of effort into hacking a system.
By the same notion one could say that the system that i helped develop is even better then anything Microsoft have ever developed because it has never needed any securitypatches what so ever. A system used by one customer and its an fully internal system. Now is it likely that its 100% safe because of this...hell no.
So "Few security patches" <> "Secure". Lets not go the Mac fanatics way plz. (or Linux for that matter).
/T
June 20, 2011 at 6:39 am
Hi Steve, a bit off topic, but may I add an update to the Patchday last week - the situation (at least here in Europe) looks unfortunately a bit different 🙁
First of all, MS included some Security Patches for SQL 2K5 and 2K8, in addition to the already mentioned other Windows components that could cause troubles to a SQL instance (like Firewall, Group Policies, .NET, etc.). According to Sec Bulletins 16(!) patches were released!
Second the patches seem to produce some serious problems in some specific environments.
Third (and this the worst of all), the patches are partly not uninstallable, the corresponding "how to remove" entry in the KnowledgeBase goes like "backup all your data, uninstall the whole SQL Server instance, grab your original media and reinstall" - this is in my opinion a fully unserious way to produce security patches!
Short description of my recent findings (I know, very unusual/obsolete combination of components, but this is how often real life looks like):
Small Business customer, I was never able to persuade the client to purchase a dedicated database server, so inspite of my recurring recommendations all tasks are running on just one poor old piece of hardware (domain controller, fileshare, antivirus, backup, print server, Exchange, God knows what else...)
Again typical small business customers - there is no dedicated system administrator available, someone in the company "who knows anyway" just turns around the knobs as this is cheaper than to hire an external professional.
There is (was) an SQL 2000 instance with all patches and SP4 running, migration and upgrade to current versions was omitted to spare the licence costs.
Some additonal SQL2K5 (Express) instances were silently installed by additional software components (backup solution, antivirus, online banking).
Friday night (an optimum on timing!) the patches hit the server and found the SQL2K5 instances (whoever activated automatic updates on a productive server should be roasted slowly on charcoal, but this is an other story).
The result was that saturday morning all SQL instances were found dead on the machine, removal or reinstallation was not possible as the operating system was apparently completely confused. Services were deactivated, communication and firewall policies changed, standard 1433 port reconfigured, backup (also using SQL) failed, restore was not executable.
I might be mistaken, English is not my mother tongue, but I believe, this is the situation that can be best described by the acronym FUBAR in the English language(?)
So I was forced to set up a completely new server over the weekend as a dedicated DB server - but think positive! At least my recommendation for a new server is not in vain any more 😀
Nevertheless, I find the way Microsoft patches, sometimes rather unprofessional - first they put some unfinished and/or vulnerable products on market as the time pressure is too high or the announced release dates are over. Later on, when the vulnerabilities hit the market they react - again under time pressure - with patches that are often not reversible and sometimes produce more problems than you possibly had without. Finally they do not care if someone could possibly use something that is not fresh out of the box - just the way they keep on killing common controls and other components that are still very widely used by many old, pre .NET applications.
Of course I understand, old systems can not be supported forever - but nobody talks here about providing support, just why not leave legacy systems as they are?! If there is anything not clear during a patch installation (like finding a previous/obsolete version) it would be better to cancel the patch instead of forcibly breaking down the whole system.
Cheers, Richard.
June 20, 2011 at 8:21 am
Agreed, Microsoft patching is nowhere close to what a true 24x7 mission critical OS should be. Requiring reboots is ridiculous (Novell Netware didn't, even for kernel patches, much less mainframe OS's). Not having a good, reliable, clean uninstall for all patches is also completely contrary to reliable operation: "What is your strategy in case of issues" being "Hope or reinstall with lots of downtime" isn't a good option.
That said, does anyone know of a more comprehensive way within SQL Server to determine what patches are installed at the OS level than the very basic:
CREATE TABLE #xp_msver
(
id int,
Name varchar(128),
Internal_Value int,
Character_Value varchar(128)
);
INSERT INTO #xp_msver
EXEC master.dbo.xp_msver;
SELECT Character_Value FROM #xp_msver WHERE Name = 'WindowsVersion'
DROP TABLE #xp_msver
SELECT SERVERPROPERTY('ProductVersion'), SERVERPROPERTY('ProductLevel')
June 20, 2011 at 8:52 am
Not really more comprehensive 🙂
You can try to use WMI for this - here some possible hints:
http://msdn.microsoft.com/en-us/library/ms180606(SQL.90).aspx
http://msmvps.com/blogs/athif/archive/2005/11/20/76035.aspx
Hope this helps or gives you some ideas...
Regards, Richard.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply