Hace algunas semanas recibí una llamada de uno de nuestros clientes en relación a la instalación del Service Pack 3 (SP3) en SQL Server 2005. El cliente estaba llevando a cabo la instalación del Service Pack a través de Microsoft Update (Microsoft Update es una opción dentro de Windows Update que permite llevar a cabo la actualización no sólo de Sistema Operativo Windows sino también de otro software Microsoft como Office o SQL Server) y la instalación se completaba con éxito sin embargo, Windows Update continuaba reportando el SP3 de SQL como instalación requerida. No importa cuántas veces se intentase llevar a cabo la instalación, Microsoft Update siempre mostraba la instalación con éxito pero siempre volvía a solicitar la instalación del Service Pack.

En nuestro caso la versión original de SQL Server correspondía con SP2 (build 2005.90.3042) de manera que el error no estaba en el motor de detección de Microsoft Update. Le pedí al cliente que relizase la descarga del SP3 desde la zona de descargas de Microsoft ya que la instalación de forma atendida permite un mayor control del proceso. El cliente reportaba que la instalación se completaba también con éxito, pero que la versión del producto seguía siendo 3042.

Revisando el fichero de registro de instalación summary.txt, que por defecto se encuentra en el directorio C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\Log, encontramos la siguiente información:

Products Detected Language Level Patch Level Platform Edition
Setup Support Files ENU 9.3.4035 x86
SQL Server Native Client ENU 9.00.4035.00 x86
MSXML 6.0 Parser ENU x86
SQLXML4 ENU 9.00.4035.00 x86
Microsoft SQL Server VSS Writer ENU 9.00.4035.00 x86

Como seguramente habrás observado, hay un componente que falta en esta lista: Database Services (el motor de Base de Datos). El número de versión de SQL Server que podemos ver a través de SQL Server Management Studio o mediante la consulta de la función del sistema @@version se corresponde con la versión de este componente (la misma versión que muestra el ejecutable sqlserver.exe en el directorio de programa de SQL Server). El instalador del SP3 (build 4035) estaba reportando una instalación correcta para los componentes compartidos, que eran los únicos componentes detectados en nuestro caso.

Para estudiar el problema con más detalle ejecutamos Process Monitor durante la ejecución del archivo de instalación del SP3 y descubrimos varios eventos de ACCESS DENIED que no fui capaz de reproducir en mi entorno de pruebas; la mayoría de estos eventos estaban relacionados con el componente Wmiprvse.exe. Nos decidimos a comprobar el estado del servicio WMI (Windows Management Intrumentation) con la ayuda de la Utilidad de Diagnósticos de WMI (WMI Diagnostics Utiliy o simplemente WMIDiag). Tal y como esperábamos, WMIDiag mostró diferentes errores de configuración del servicio WMI:

34153 10:34:38 (0) ** WMIDiag v2.0 started on dinsdag 21 juli 2009 at 10:25.
34154 10:34:38 (0) **
34155 10:34:38 (0) ** Copyright (c) Microsoft Corporation. All rights reserved - January 2007.
[...]
35235 10:34:39 (0) ** DCOM security warning(s) detected: ........... 0.
35236 10:34:39 (0) ** DCOM security error(s) detected: ............. 2.
35237 10:34:39 (0) ** WMI security warning(s) detected: ............ 0.
35238 10:34:39 (0) ** WMI security error(s) detected: .............. 52.
35239 10:34:39 (0) **
35240 10:34:39 (1) !! ERROR: Overall DCOM security status: ......... ERROR!
35241 10:34:39 (1) !! ERROR: Overall WMI security status: .......... ERROR!
[...]
35401 10:34:39 (0) ** ERROR: WMIDiag detected issues that could prevent WMI to work properly!.  Check 'C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMP\WMIDIAG-V2.0_2003_.SRV.RTM.32_NF04_2009.07.21_10.24.40.LOG' for details.
35402 10:34:39 (0) **
35403 10:34:39 (0) ** WMIDiag v2.0 ended on dinsdag 21 juli 2009 at 10:34 (W:181 E:57 S:1).

En este punto parecía claro que nuestro problema original estaba en la configuaración del servicio de WMI. Gracias a la ayuda de Carlos Carrolo, del equipo de Soporte a Plataforma Microsoft, fuimos capaces de relacionar nuestro problema con el siguiente artículo de la Knowledge Base (KB):

Algunos o todos los servicios de SQL Server 2005 no aparecen en el Administrador de configuración de SQL Server, o si recibe un mensaje de error "No SQL Server 2005 components were found" al realizar operaciones en configuración de superficie de SQL Server 2005

El hecho de que ninguno de los servicios de SQL Server fuera listado en SQL Server Configuration Manager confirmó nuestras sospechas (esto es descrito como uno de los síntomas en el propio KB).

Este artículo de la Knowledge Base no mencionaba nuestro escenario con el archivo de instalación del SP3, pero la solución propuesta nos permitió resolver el problema. El artículo es bastante específico explicando las causas del problema: durante la primera fase del proceso de instalación del Service Pack los servicios de SQL Server son descubiertos a través de consultas WMI y mediante el uso del proceso Wmiprvse.exe; sin los permisos adecuados el proceso fallará el tratar de descubrir los componentes instalados. Este se describe en mayor detalle en la última parte del artículo:

[…] Estas herramientas recorrer en iteración la colección de servicios para obtener información acerca de los servicios de SQL Server 2005. Cuando estas herramientas recorrer en iteración la colección de servicios, estas herramientas generan las consultas de Instrumental de administración de Windows (WMI) siguientes:

  • SELECT * FROM RegServices
  • SELECT * FROM SqlService
Cuando estas herramientas generan las consultas WMI, el proveedor de SQL Server Web-Based Enterprise Management (WBEM) (Sqlmgmprovider.dll) se carga en el proceso Wmiprvse.exe. A continuación, el proveedor de WBEM de SQL Server extrae y procesa la información acerca de los servicios de cada instancia de SQL Server 2005 […] El proceso Wmiprvse.exe en el que cargar el archivo Sqlmgmprovider.dll se ejecuta bajo el contexto de seguridad de la cuenta NETWORK SERVICE. […]

Todo apuntaba a que, en algún momento después de la instalación del SP2 de SQL Server, el servidor Windows había sido actualizado con una nueva Directiva de Seguridad que modificó la Discretionary Access Control List (DACL) de SQL Server, dando lugar a un funcionamiento incorrecto del mecanismo de detección de WMI.

-- Jorge Pérez Campo, Microsoft Customer Support Services