As I mentioned in my very first post, I’m starting to mess around with the policy based management (PBM) features on SQL 2008. Since I am in a mixed environment with both SQL 2008 and SQL 2000 servers, one thing I needed to be aware of right away is that PBM will work with SQL 2000, but not completely. There are limits as to what can be done to a 2000 server (and 2005 as well) and those limits are detailed here. Fortunately, Microsoft has provided some extended functionality to overcome these limitations in the form of the Enterprise Policy Management Framework. The EPMF however, requires your Central Management Server be at 2008 SP1 CU3 or higher. Mine were not. Since CU7 was out, I went ahead and planned to update my servers to CU7. (Actually, CU8 was out as well, but somehow I missed that one, so I only went to CU7.)
One of my 2008 SQL servers is a two node active / passive cluster. Since SQL cumulative updates and service packs are cluster aware, I didn’t think I’d have any problems installing CU7. But I did. My first attempt at installing failed. Checking the logs, I saw this error:
Instance MSSQLSERVER overall summary:
Final result: The patch installer has failed to update the shared features. To determine the reason for failure, review the log files.
Exit code (Decimal): -2068709375
Exit facility code: 1202
Exit error code: 1
Exit message: The directory ‘h:\4c9c78c622cc78cb1cfde9b431\’ doesn’t exist.
Start time: 2010-06-10 22:37:16
End time: 2010-06-10 22:37:53
Requested action: Patch
Strange directory name. Turns out, that’s just a temporary directory the installer creates. The actual name seems to be different on each machine you run it on.
But why was the installer using the H: drive? My Windows temp directory is not there. That is the drive that my .mdf files are stored on, though. Maybe the installer was picking up that fact. OK. But why did I get the “directory does not exist” error? Obviously, the installer started running from that location, so it could find it at one point.
The answer turned out to be in the clustering setup. As you can see, my H: drive is defined in my cluster. It is also a dependency for the SQL Service service on the cluster.
What was happening is the Cumulative Update installer was shutting down the SQL Server service. When this happened, the dependent network drives were also shutdown. So the H: drive disappeared halfway through the installation!
How do you get around this? I simply stopped the SQL Server service myself before running the update. I noticed then that the installer used the C: drive for the location of the temporary directory and everything proceeded smoothly after that. In fact, the update even started the SQL Server service when it was done, so I was good to go.