To SQL or not to SQL

Swiss Vodka - xellent

A Russian Colleague living here in Switzerland told me about Swiss produced Xellent Vodka 6 weeks ago. She swore by it.

So, the next day I went and bought a bottle, went to friends for dinner, put it in their freezer and 4 hours later, I took the bottle in my grip and promptly finished half of it over dinner (I was greedy and would not share). The next morning I had no hangover and promptly had a bit more. I swear by the stuff, it is very good. Pity it is not available as a small bottle for me to keep on me during those long meetings or when I am getting cold whilst waiting for the tram here in Zurich.

It is not cheep, but it is very good. I rather pay with my wallet than pay with a hangover and since I am really only a vodka drinker (ok, under duress a beer will do, or a very decent Cognac), I think the best will only do.

Have a look at their site http://www.xellent.ch

Windows Task Scheduler (a.k.a Task Scheduler) and SQL Server 2000/2005

After the problems on the SQL Server 2000 cluster with the new hotfix installer, a case was opened with Microsoft Support engineer allocated to us (see article prior to this).

Well, after some more looking, SQL Server 2005 will use Windows Task Scheduler for setup on Clusters too.

OK, but Microsoft recommends that you disable Task Scheduler as a security precaution. Great.

According to the SQL Development team, the use of Task Scheduler is here to stay. In some respect I see where they are coming from as they can then use the "Run As" on the remote host to launch the process under the correct account.

Currently, if things fail, the task is left on the remote machine, but the directory the task refers to is deleted.

We have now opened a DCR (Change request) that Microsoft either documents this feature and process very well, including updating their security lockdown documentation, or make the hotfix installer/Setup clever enough to start the task scheduler on the remote hosts, run the processes required and shut it down again.

SQL Server 2000 post SP4 hotfixes don't install on all nodes of a cluster

I recently installed a new Windows 2003, SQL Server 2000 cluster.

Then added SQL Server 2000 SP4 and applied hotfix 2040 (KB 899761 FIX: Not all memory is available when AWE is enabled on a computer that is running a 32-bit version of SQL Server 2000 SP4)

By chance I looked at the sqlservr.exe file and noticed it was still 2039 on all non-active nodes for the instance, whilst the node I installed the hotfix from was at 2040.

I looked at the SQL2000-KB8997618.00.2040-x86-ENU.log log file that 2040 creates.

3.781: SQL DLL: Successfully transferred payload to remote product instance target \\NodeB
3.781: SQL DLL: Successfully transferred payload to remote product instance target \\NodeB
3.797: SQL DLL: Successfully created new scheduled task for product instance target \\NodeB
3.828: SQL DLL: Error, failed to save new scheduled task for product instance target \\NodeB
3.828: SQL DLL: Error, failed to create scheduled task for product instance target \\NodeB
4.000: SQL DLL: Successfully removed remote folder for product instance target \\NodeB
4.000: SQL DLL: Error, remote process failed for product instance target NodeB
5.031: SQL DLL: All remote clustered nodes have completed patch installation
5.031: SQL DLL: Checking that at least one remote clustered node was successful
5.047: SQL DLL: Remote clustered node NodeB was successfully patched
5.047: SQL DLL: One or more remote clustered nodes were successfully patched

What?
On step 3.828 it fails, but then still claims on 5.047 to have checked that the hotfix was there.

Not the case, it failed and 2040 is not on the other nodes.

As you may nor may not know, Microsoft has changed the hotfix installer for SQL Server. What they did not tell us is that it now relies on Windows Task Scheduler to do it's work on the other nodes of the cluster.

What it boils down to is that if Windows Task Scheduler is disabled or not running on the remote nodes, the hotfix install on those nodes fails, but fails very silently.
Most corporates disable Windows Task Scheduler as it is a potential security risk.

So, before you apply any SQL Server 2000 post SP 4 hotfixes on a cluster, enable and start Windows Task Scheduler on all the nodes of the cluster (stop and disable them once you are finished before your security team come and get you).