Esecuele Sin Fronteras

Error "Unable to load client print control" en Reporting Services 2005 (MS09-062)

2009-12-03T11:42:00Z

Puede que os encontréis este error después de instalar las actualizaciones de seguridad de Octubre (como MS09-062: http://support.microsoft.com/kb/971023)

Para solucionarlo, tendréis que instalar lo siguiente:

- CU6 de SQ Server 2005 SP3 (http://support.microsoft.com/kb/974648).

- Si utilizáis CRM, SharePoint o alguna otra aplicación que utilize el visor de informes para mostrarlos, e intentéis imprimirlos, tendréis que instalar el Report Viewer Redistributable 2005 SP1 (http://www.microsoft.com/downloads/details.aspx?familyid=E7D661BA-DC95-4EB3-8916-3E31340DDC2C&displaylang=en).

Maria Esteban

Reporting Services Support Engineer

El Setup de SQL Server 2005 Service Pack 3 no actualiza la instancia de Analysis Services

2009-11-18T17:40:00Z

Os comentaré en este post un problema con el que me he encontrado al querer actualizar los componentes de SQL Server 2005 en un cluster de 2 nodos. Tengo una instancia de SQL Server 2005 y una instancia de Analysis Services. Ejecuto el Service Pack 3, la instancia de SQL Server 2005 se me actualiza correctamente al SP3, sin embargo la instancia de Analysis Services no se actualiza y da un fallo indicando que estamos ejecutando la instalación en el nodo pasivo (cuando sin embargo sí estamos en el nodo activo!). El error es el siguiente:

"This installation must be run from the active node. You are running it from a passive node. To proceed, cancel the installation and run it again from the active node."

En el fichero hotfix.log de instalación del Service Pack (por defecto en la carpeta C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap), se puede ver la información siguiente:

11/17/2009 17:18:12.173   Instance Details: MSSQLSERVER
11/17/2009 17:18:12.173     agentservicename = SQLSERVERAGENT
11/17/2009 17:18:12.173     associatedhotfixbuild = 4261
11/17/2009 17:18:12.173     clustername = CLUSNAME
:   :   :   :   :
11/17/2009 17:18:12.188   Instance Details: MSSQLSERVER
11/17/2009 17:18:12.188     associatedhotfixbuild = 1520
11/17/2009 17:18:12.188     clustername = CLUSNAMEX

La primera parte del hotfix.log que muestro aquí corresponde a SQL Server Agent, y la segunda a OLAP.
Vemos que el clustername es distinto. En ambos casos debería ser el mismo.
No he identificado el porqué de esta diferencia (sospecho que se instaló anteriormente una aplicación con este nombre CLUSNAMEX como referencia).
En cualquier caso, para salir de esta situación he seguido los pasos siguientes:

- En el nodo actual (donde se ejecuta el Setup, y que es activo para Analysis Services), abrir el registro
- Ir a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.2\Cluster
(En mi caso MSSQL.2 es el identificadorr para la instancia existente de Analysis Services)
- comprobar que esta clave apunta a CLUSNAMEX
- Parar la replicación de la clave de regitro entre los nodos:
cluster res "Analysis Services" /removecheck: "Software\Microsoft\Microsoft SQL Server\MSSQL.2\Cluster"
- Cambiar el valor a CLUSNAME en ambos nodos
- Habilitar de nuevo el checkpointing:
cluster res "Analysis Services" /addcheck: "Software\Microsoft\Microsoft SQL Server\MSSQL.2\Cluster"

Después de esto la instancia de Analysis Services se actualizó correctamente al Service Pack 3.

Para más información acerca de la instalación de Analysis Services en cluster, podéis consultar el artículo siguiente: http://support.microsoft.com/kb/910230.

Espero que esta información os resulte útil.

Marcos Celada

Ingeniero de soporte de SQL Server

Recomendaciones para evitar problemas de conectividad con SQL y TCP Chimney

2009-11-11T11:15:00Z

Hoy vamos a comentar una situación que hemos observado frecuentemente: Distintos problemas de conectividad al tener activada la opción TCP Chimney.

TCP Chimney es una característica que incluida en Windows 2003 SP2, en el Scalable Networking Pack (SNP) de Windows 2003, y, por defecto, en Windows 2008. Lo que permite es que parte del procesamiento se realice en el adaptador de red, por lo que reduce el consumo de CPU del procesador. Para que este traspaso de carga sea posible, el adaptador de red tiene que ser compatible con esta opción.

Sin embargo, hemos observado que activar esta característica con SQL Server en Windows 2003, puede provocar distintos errores relacionados con conectividad. El mensaje puede ser variado y normalmente muy genérico, del tipo: “General Network Error” o “Transport-level error”. Si nuestro SQL está conectándose a otros sistemas (por ejemplo, un servidor vinculado Oracle) el mensaje de error puede estar encapsulado en un mensaje del proveedor utilizado.

Por lo tanto, si estáis teniendo errores aleatorios de conectividad, y tenéis activado la opción TCP Chimney, os recomendamos deshabilitarlo en las dos máquinas involucradas (origen y destino de la conexión).

En los siguientes links tenemos la información de cómo deshabilitarlo:

- http://support.microsoft.com/kb/948496

- http://support.microsoft.com/kb/942861

Un saludo,

Raquel Vicente de la Rosa

Ingeniero de Soporte de SQL Server

Nuevo Blog de BizTalk

2009-11-04T11:48:00Z

Hola a todos.

Comentaros que he creado un nuevo blog de BizTalk en castellano donde podréis encontrar post más específicos de este producto.

Un saludo

Enrique Palomino | BizTalk Escalation Engineer

El email de mi subscripción no llega al destinatario

2009-10-19T09:54:00Z

La manera en la que las subscripciones son procesadas por parte de Reporting Services es mandando el informe a un directorio de recogida (pickup directory) donde será recogido por el servidor SMTP y lo mandará al destinatario final.

Cuando el email (subscripción) no llega a su destino, empezaremos a investigar si el problema está en Reporting Services o en el servidor de correo.

Una forma rápida de averiguarlo es hacienda la siguiente prueba: configurar el SMTP utilizando IIS y cambiar el fichero de configuración de la siguiente manera:

Esto creará un fichero eml en el directorio C:\eml (hay que crearlo a mano primero o especificar uno que ya exista). Y asegurarse de que la cuenta de servicio de REporting Services tenga permisos sobre el directorio.

Si al ejecutar la subscripción, el fichero eml aparece en el directorio, esto significa que el problema está en el servidor de correo.

Más información:
Cómo configurar un servidor de informes para la entrega por correo electrónico (Configuración de Reporting Services) http://technet.microsoft.com/es-es/library/ms345234.aspx

Bajo “Para configurar un servicio SMTP local para el servidor de informes”

Maria Esteban

Reporting Services Support Engineer

Pueden RS 2005 y RS 2008 coexistir en la misma máquina?

2009-10-19T09:36:00Z

Sí, siempre que:

1. No sea Windows XP 32

2. Y que las urls utilizadas para conectarse a RS 2005 y a RS 2008 sean diferentes

Reporting Services 2008 y Reporting Services 2005 (IIS 6 o superior) pueden coexistir en la misma máquina bajo la mayoría de los Sistemas Operativos sin causar conflictos entre ellos. La única excepción es Windows XP 32 bits (IIS 5.1). En este caso, habrá que utilizar puertos diferentes.

RS 2005 (IIS) y RS 2008 usan “url reservations” desde HTTP.SYS. IIS usa “Wildcard reservations” y RS 2008 usa “Strong Wildcard reservations” por defecto.

Por esta razón, si utilizásemos la misma url en RS 2008 y en RS 2005 (Directorio virtual en IIS) con el mismo nombre y puerto, sería RS 2008 quien atendiera la petición.

Maria Esteban

Reporting Services Support Engineer

Como resolver errores de TimeOut en Reporting Services

2009-09-29T12:30:46Z

Al trabajar con Reporting Services,os podéis encontrar con diversos errores de timeout. Esto puede suceder al ejecutar informes pesados. Abajo encontraréis diferentes tipos de timeouts y cómo cambiar sus valores.

1. Si el timeout se produce en la ejecución de la consulta del informe, se puede modificar este valor desde el Diseñador de informes. Para ello sigue los siguientes pasos:

· Abrir el informe utilizando el diseñador de informes (Business Intelligence)

· Seleccionar la pestaña de datos

· Seleccionar las propiedades del dataset

· Incrementar el valor del timeout (o poner el número de minutos permitidos para la duración de la consulta si estuviese vacío)

2. Si el timeout se produce por la duración de la ejecución del informe completo, se puede aumentar en la propiedad bajo la opción 'Do not timeout report execution'

Más información en:

http://msdn2.microsoft.com/en-us/library/ms179924.aspx

http://msdn2.microsoft.com/en-us/library/ms183733.aspx

3. Si el timeout es debido que la session haya expirado, se puede modificar el sessionState en el fichero de configuración web.config que está en la ruta “C:\Programme\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportManager”

<sessionState mode="InProc" cookieless="false" timeout="180" />

Reiniciar IIS (Inicio - Ejecutar…, escribit iisreset y hacer clic en Aceptar).

EN EL SERVIDOR

4. Si el timeoout es causado por la conexión al servidor de base de datos, se puede cambiar el timeout de la conexión a 7200 segundos (por defecto es 120 segundos)

· Abrir IIS

· Hacer right clic en el sitio web donde está el Report Server

· Seleccionar las Propiedades

· Si el timeout de la conexión es menor que 7200, se podría incrementar a 7200

5. En el fichero RSReportServer.config se pueden modificar los siguientes valores (valore de ejempo):

<Add Key="ProcessRecycleOptions" Value="1"/> 

<Add Key="CleanupCycleMinutes" Value="36000"/> 

<Add Key="SQLCommandTimeoutSeconds" Value="0"/> 

<Add Key="MaxActiveReqForOneUser" Value="100"/>

<Add Key="DatabaseQueryTimeout" Value="0"/> 

<Add Key="RunningRequestsScavengerCycle" Value="36000"/> 

<Add Key="RunningRequestsDbCycle" Value="36000"/> 

<Add Key="RunningRequestsAge" Value="30"/>

6. Comprueba el valor del ExecutionTimeout en el fichero web.config

\Program Files\Microsoft SQL Server\MSSQL.X\Reporting Services\ReportManager\

y

\Program Files\Microsoft SQL Server\MSSQL.X\Reporting Services\ReportServer)

Por defecto es 9000 segundos, que son 2.5 horas.

Compruba los valores en los dos ficheros web.config

( ejemplo: <httpRuntime executionTimeout = "9000" /> ).

Puedes aumentar este al valor a 36000.

Maria Esteban

Reporting Services Support Engineer

El Service Pack de SQL Server 2005 no Actualiza Todos los Componentes

2009-09-08T15:09:36Z

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

Cómo Abrir Fácilmente los Puertos del Firewall de Windows para SQL Server

2009-08-25T15:55:49Z

El pasado día, tras realizar una instalación de SQL Server 2008 en mi portátil con Windows 7, me encontré sin poder conectar a la instancia utilizando SQL Server Management Studio (SSMS). Recordaba que debido a los cambios introducidos en el Firewall de Windows Server 2008 y Windows Vista esto se debía con seguridad a puertos requeridos por SQL Server que no estaban abiertos en el Firewall.

La sección Configurar Firewall de Windows para permitir el acceso a SQL Server de la documentación en línea de SQL Server incluye información sobre cómo abrir en el Firewall de Windows los puertos requeridos por los diferentes servicios de SQL Server. Sin embargo, buscando esta información descubrí una manera mucho más sencilla de abrir estos puertos en el artículo de la Knowlege Base KB968872:

El artículo incluye la opción de resolución automática Microsoft "Fix it" que permite solucionar de manera sencilla el problema en cuestión a través de un sencillo programa de setup. El setup de "Fix it" en este artículo está diseñado para Windows Server 2008 pero el script que es finalmente ejecutado por este setup está incluido en el mismo artículo y puede ser ejecutado tanto en Windows Vista como en Windows 7:

@echo ========= SQL Server Ports ===================
@echo Enabling SQLServer default instance port 1433
netsh firewall set portopening TCP 1433 "SQLServer"
@echo Enabling Dedicated Admin Connection port 1434
netsh firewall set portopening TCP 1434 "SQL Admin Connection"
@echo Enabling conventional SQL Server Service Broker port 4022
netsh firewall set portopening TCP 4022 "SQL Service Broker"
@echo Enabling Transact-SQL Debugger/RPC port 135
netsh firewall set portopening TCP 135 "SQL Debugger/RPC"
@echo ========= Analysis Services Ports ==============
@echo Enabling SSAS Default Instance port 2383
netsh firewall set portopening TCP 2383 "Analysis Services"
@echo Enabling SQL Server Browser Service port 2382
netsh firewall set portopening TCP 2382 "SQL Browser"
@echo ========= Misc Applications ==============
@echo Enabling HTTP port 80
netsh firewall set portopening TCP 80 "HTTP"
@echo Enabling SSL port 443
netsh firewall set portopening TCP 443 "SSL"
@echo Enabling port for SQL Server Browser Service's 'Browse' Button
netsh firewall set portopening UDP 1434 "SQL Browser"
@echo Allowing multicast broadcast response on UDP (Browser Service Enumerations OK)
netsh firewall set multicastbroadcastresponse ENABLE

Al ejecutar este script en Windows 7 se mostrarán varios mensajes de "warning" ya que el comando netsh firewall se encuentra depreciado en Windows 7 (netsh advfirewall firewall es el comando recomenado) aunque el script funcionará en cualquier caso.

¡Gracias por este script al equipo de Microsoft "Fix it"!

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

Errores en el visor de eventos y errorlog realizando una instalación de SQL 2008 + SP1 Slipstreaming

2009-08-11T16:04:00Z

Una pequeña introducción: Se llama instalación slipstreaming cuando con un solo proceso de instalación instalamos un producto y el service pack correspondiente. En algunos casos Microsoft provee directamente de los binarios para esta instalación (el caso más famoso Windows XP + SP2) y en otros casos, del proceso para crearlos. Este último es el caso de SQL 2008 + SP1. El proceso viene descrito en: http://support.microsoft.com/kb/955392 - Procedure 1: Basic slipstream steps

Si nos decidimos por este método de instalación: Una vez terminado el proceso, una práctica recomendada es revisar logs de instalación, visores de entos, logs de SQL… para confirmar que todo ha ido según lo esperado. Sin embargo, en esta instalación, al revisar el visor de eventos de aplicación y/o el errorlog, podemos llevarnos una pequeña sorpresa.

El visor de eventos y el errorlog tendrá un alto número de entradas similares a:

Error: 15151, Severity: 16, State: 1.

Cannot find the object 'nombre_objeto', because it does not exist or you do not have permission.

Estos errores se pueden ignorar de forma segura, ya que no indican un problema real en la instalación.

Estas líneas con error son debidas al orden en el que se ejecutan las distintas acciones en una instalación con slipstreaming: en un punto intermedio de la instalación, parecen estas líneas de error, sin embargo, al final del proceso completo, todos los objetos son creados correctamente y con las propiedades adecuadas.

Una instalación en la que sólo nos encontremos estos errores puede ser considerada una instalación limpia, y no hay ninguna razón por la que deba tener errores en un futuro.

Espero que este post os ahorre algún quebradero de cabeza.

Un saludo.

Raquel Vicente de la Rosa

Ingeniero de Soporte de SQL Server

Como conectar a Sybase ASE desde Reporting Services utilizando del proveedor ADO.NET:

2009-08-11T10:49:00Z

Como ya sabemos, Reporting Services puede conectarse a diferentes servidores de bases de datos aparte de SQL server. En este post, comentamos como configurar Reporting Services para poder crear orígenes de datos que se puedan conectar a Sybase utilizando el proveedor de ADO.NET.

Lo podemos hacer de dos maneras:

· Utilizando una extensión de datos:

Una forma, quizás la más compleja, sería creando una extensión de procesamiento de datos. Para ello habrá que modificar los ficheros de configuración de Reporting Services rsreportserver.config y rssrvpolicy.config añadiendo una extensión para Sybase y luego darle permisos de FullTrust en segundo fichero de configuración, como explica el siguiente enlace:

Cómo implementar una extensión de procesamiento de datos en un servidor de informes

http://msdn.microsoft.com/es-es/library/ms155086.aspx

· Sin utilizar una extensión de datos:

Pero la forma más fácil, es registrando el proveedor directamente en el fichero de configuración rsreportserver.config.

Nota: ni que decir tiene, que el proveedor ASE deberá de ser previamente instalado en la máquina correctamente, para que el diseñador de informes pueda cargar las dlls del proveedor. Si, aun así, no pudiesen cargarse las dlls, se podrían incluso copiar las dlls al directorio del Report Designer directamente o a los directorios de instalación de Reporting Services

Además, es aconsejable hacer una copia de los ficheros rsReportDesigner.config y rsReportServer.config ya que van a ser modificados, por si hubiese algun problema.

Los pasos a seguir serían:

1. Parar el servicio Windows de Reporting Services

2. La modificación del fichero de configuración rsReportServer.config sería algo así. Añadiríamos lo siguiente a la sección de datos (Data)

3. Y en el fichero rsReportDesigner.config bajo la sección del diseñador (Designer)

4. Reiniciar el servicio Windows de Reporting Services

5. Hacer un reset de IIS. Esto lo podéis conseguir ejecutando iisreset desde la ventana de comandos.

Maria Esteban
EMEA GTSC Development Support Engineer
Microsoft Product Support Services

SQL Server 2008 en Cluster 2008 no se inicia

2009-08-03T11:35:00Z

Buenos días,

Voy a compartir con vosotros algunos de los pasos que sigo para intentar identificar donde está la causa de un problema concreto.

PROBLEMA

=========

Tenemos un cluster de 2 nodos con Windows Server 2008, y una instancia de SQL Server 2008 en cluster.

La instancia funciona perfectamente en el Nodo1. Hacemos un balanceo de la instancia al Nodo2. Al intentar levantar la instancia en el Nodo2, nos encontramos con que el recurso falla y se hace un failover automático al Nodo1.

La instancia VSERVER\VINSTANCE escucha por Named Pipes, TCPIP (en ip 157.58.114.35, puerto 3650)

Paso 1

=====

- Pongo los recursos offline en el Nodo1

- Hago un failover al Nodo2

- Pongo los recursos online (1 tras otro)

El recurso que falla es SQL Server.

Los errorlog de la instancia muestran también que sí se levanta la instancia, y que para de la manera siguiente:

2009-07-22 14:45:57.21 spid7s Recovery is complete. This is an informational message only. No user action is required.

: : : : : : :

2009-07-22 14:49:28.08 spid14s Service Broker manager has shut down.

2009-07-22 14:49:28.60 spid7s SQL Server is terminating in response to a 'stop' request from Service Control Manager. This is an informational message only. No user action is required.

2009-07-22 14:49:28.60 spid7s SQL Trace was stopped due to server shutdown. Trace ID = '1'. This is an informational message only; no user action is required.

Siempre puedo comprobar que la instancia se levanta durante 3m30s. El errorlog nos muestra que si SQL Server para es porque alguien le ha pedido que se pare.

En el periodo de tiempo en que la instancia está levantada, se pueden ver los errores siguientes en el log de aplicación:

Error 7/22/2009 2:46:07 PM MSSQL$NLZEI06011 19019 Failover "[sqsrvres] checkODBCConnectError: sqlstate = 08001; native error = 274d; message = [Microsoft][SQL Server Native Client 10.0]A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.

Error 7/22/2009 2:46:07 PM MSSQL$VINSTANCE 19019 Failover "[sqsrvres] ODBC sqldriverconnect failed

Error 7/22/2009 2:46:07 PM MSSQL$VINSTANCE 19019 Failover "[sqsrvres] checkODBCConnectError: sqlstate = HYT00; native error = 0; message = [Microsoft][SQL Server Native Client 10.0]Login timeout expired

Error 7/22/2009 2:46:07 PM MSSQL$VINSTANCE 19019 Failover "[sqsrvres] ODBC sqldriverconnect failed

Error 7/22/2009 2:46:07 PM MSSQL$VINSTANCE 19019 Failover "[sqsrvres] checkODBCConnectError: sqlstate = 08001; native error = 274d; message = [Microsoft][SQL Server Native Client 10.0]TCP Provider: No connection could be made because the target machine actively refused it.

Error 7/22/2009 2:46:07 PM MSSQL$VINSTANCE 19019 Failover "[sqsrvres] ODBC sqldriverconnect failed

Paso 2

=====

Al levantar la instancia en el Nodo2, en realidad, la instancia de SQL Server sí levanta, y consigo conectarme a ella utilizando la cadena de conexión TCP:157.58.114.35, 3650, pero no por el nombre VSERVER\VINSTANCE.

Por alguna razón, el proceso de IsAlive del cluster considera que la instancia de SQL Server está caída y decide apagarla y hacer el failover. Por lo que tenemos básicamente un problema de conexión a la instancia.

Paso 3

=====

Verifico en el errorlog de SQL Server que la instancia está escuchando por la ip 157.58.114.35 y el puerto 3650.

En el Nodo2, ejecuto el SQL Server Configuration Manager y verifico si tenemos algún alias.

Efectivamente, existe un alias TCP con la información siguiente:

Nombre de alias: VSERVER\VINSTANCE

Nombre de servidor: 157.58.114.35

Puerto: 365

El servicio de cluster, al querer conectarse a la instancia, utiliza este alias (creado previamente a mano, que NO existe en el Nodo1) y no lo consigue.

SOLUCION

=========

Podemos definir el alias con el puerto correcto, o directamente eliminat el alias.

Un saludo!

Marcos Celada

Ingeniero de Soporte de SQL Server

Recomendaciones para desinstalar e instalar una instancia de Reporting Services

2009-07-28T16:22:00Z

Estoy segura de que os ha pasado alguna vez que, hayáis decidido desinstalar Reporting Sercices e instalarlo de nuevo. Ya sea porque Reporting Services os da muchos errores o algo no funcione bien y queráis restaurar el estado inicial de Reporting Services.

De mi experiencia en hacer estas desinstalaciones e instalaciones os recomiendo que sigáis los siguientes pasos:

Nota: Antes de desinstalar Reporting Services, si deseáis preservar los informes ya creados, hacer copia de las bases de datos ReportServer y ReportServerTempDB y de las claves de encriptación, para luego poder restaurarlas en la nueva instalación.

1. Desinstalar Reporting Services desde “Añadir y Quitar programas” ó “Programas y funcionalidades” (si lo hacéis desde Windows Vista ó 2008)

2. Borrar manualmente las bases de datos de configuración ReportServer y ReportServerTempDB del SQL Server utilizando “Management Studio”.

Si quisieseis preservar los informes ya creados, no borréis las bases de datos sino que habrá que hacer un Backup y luego reconectarlas desde la nueva instalación (usando el Configuration Manager bajo la sección de “Conexión de base de datos”).

3. Borrar manualmente los directorios virtuales Reports y ReportServer creados en IIS (sólo si la versión de RS es 2005 ya que 2008 no utiliza IIS)

4. Borrar manualmente el directorio de la instancia de Reporting Services (por ejemplo, para RS 2008, el directorio sería algo similar a esto C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER). Si este directorio no se borra manualmente antes de la nueva instalación, podríamos arrastrar errores causados por la configuración antigua.

5. Instalar la nueva instancia de Reporting Services utilizando un usuario administrador

6. Instalar el último Service Pack (el nivel de Service Pack tendrá que ser el mismo que la versión del SQL Server donde se guardarán las bases de datos de configuración ReportServer y ReportServerTempDB.

7. Configurar Reporting Services utilizando el Reporting Services Configuration Manager.

Espero que esto elimine los temores de desinstalar e instalar RS.

Maria Esteban
EMEA GTSC Development Support Engineer
Microsoft Product Support Services

No Utilices Cluster Server Recovery Utility en Servidores Windows de 64-bits

2009-07-13T14:46:17Z

Posiblemente ya conozcas la utilidad Cluster Server Recovery, una herramienta de Windows Server 2003 que puede emplearse para facilitar diferentes tareas asociadas con la gestión del Clúster (recuperación de ficheros de checkpoint, cambio de firmas de disco, migración de discos, etc.)

La página de descargas de esta utilidad indica claramente que no está soportada en entornos de Clúster de 64-bits, a pesar de ello he encontrado recientemente varios casos con errores en instancias de SQL Server que estaban producidos por un uso incorrecto de esta herramienta en servidores de 64-bits.

El uso de de esta utilidad en instalaciones en Clúster de SQL Server puede dar lugar a problemas bastante complejos y bastante costosos en tiempo de solucionar. Por esta razón creo que merece la pena destacar de nuevo aquí la importancia de no usar esta herramienta en 64-bits.

¿Qué errores puedo encontramre como consecuencia de usar esta herramienta en servidores de 64-bits?

Alguno de los errores que pueden resultar de ejecutar Cluster Recovery Tool en 64-bits son:

El servicio SQLBrowser no pudo establecer la instancia de SQL y la detección de conectividad. (Visor de Eventos de Aplicaciones en instalaciones en Idioma Español)

The SQLBrowser service was unable to establish SQL instance and connectivity discovery. (Visor de Eventos de Aplicaciones en instalaciones en Idioma Inglés)

Inicialización de TDSSNIClient falló con error 0x2, código de estado 0x35. (Fichero Errorlog de SQL Server en Idioama Español)

Server TDSSNIClient initialization failed with error 0x2, status code 0x35. (Fichero Errorlog de SQL Server en Idioma Inglés)

¿Cómo puedo saber si esta aplicación ha sido ya usada en mi entorno?

Al ejecutar esta herramienta se generan entradas similares a esta bajola entrada Wow6432Node del Registro de Windows:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server\MSSQL.x]

Oops, creo que he usado esta herramienta en mi clúster de 64-bits, ¿qué debo de hacer?

Solucionar los errores derivados del uso incorrecto de esta herramienta require la modificación de varias claves del Registro y no es un proceso sencillo. Por favor, contacta con los Servicios de Soporte de Producto de Microsoft para solicitar ayuda en este caso.

- Jorge Pérez, Microsoft Customer Support Services

Error en la solicitud de inicio del servicio 'SQLBrowser' Durante la Instalación de SQL Server 2008

2009-06-03T19:59:00Z

El pasado día me encontré con un problema bastante curioso durante la instalación de SQL Server 2008 y creo que merece la pena compartir aquí lo que descubrí. En este caso mi cliente estaba llevando a cabo una instalación de SQL Server 2008 en un ordendador con Windows XP SP3 para dar soporte a un paquete de ERP instalado localmente.

El proceso de instalación de SQL Server 2008 parecía funcionar bien inicialmente pero fallaba en un determinado punto con el siguiente mensaje de error:

Error en la solicitud de inicio del servicio ‘SQLBrowser’. Haga clic en Reintentar para reintentar la accion o haga clic en Cancelar para cancelar el proceso de instalación.

Pulsando en el botón Reintentar llevaba a cabo un nuevo intento de arrancar el servicio, pero fallaba de nuevo con el mismo error de modo que no había otra opción que no fuese cancelar el proceso de instalación.

El Visor de Eventos de Windows no mostraba ninguna pista acerca del origen del error de manera que decidí comprobar el fichero de registro de instalación de SQL Server 2008 que se encuentra en la carpeta C:\Archivos de Programa\Microsoft SQL Server\100\Setup Bootstrap\Log. Existen diferentes archivos de registro en esta carpeta y cada uno de ellos proporciona información específica para un componente de SQL Server (SSIS, AS, Motor de Base de Datos, Herramientas Cliente, etc.). El fichero Detail.txt incluye información detallada de proceso global de instalación y es normalmente el primer fichero que abro a la hora de investigar un problema de instalación; esto fue lo que encontramos en nuestro caso:

2009-05-14 17:25:13 SQLBrowser: The last attempted operation: Iniciando el servicio SQL Server Browser 'SQLBrowser' y esperando hasta '900' segundos para que se complete el proceso. .
2009-05-14 17:25:13 Slp: Prompting user if they want to retry this action due to the following failure:
2009-05-14 10:25:13 Slp: ----------------------------------------
2009-05-14 17:25:13 Slp: The following is an exception stack listing the exceptions in outermost to innermost order
2009-05-14 17:25:13 Slp: Inner exceptions are being indented
2009-05-14 17:25:13 Slp:
2009-05-14 17:25:13 Slp: Exception type: Microsoft.SqlServer.Configuration.Sco.ScoException
2009-05-14 17:25:13 Slp: Message:
2009-05-14 17:25:13 Slp: Error en la solicitud de inicio del servicio 'SQLBrowser'.
2009-05-14 17:25:13 Slp: Data:
2009-05-14 17:25:13 Slp: Feature = SQL_Browser_Redist_SqlBrowser_Cpu32

Aquí podíamos ver que efectivamente el servidio SQLBrowser había sido creado pero no podía ser arrancado por alguna razón. A continuación pasé al archivo de registro de instalación Summary.txt que proporciona un resumen de los eventos llevados a cabo durante el proceso; este fichero puede encontrarse también bajo la carpeta \LOG e incluye un lista de qué componentes han sido instalados con éxito y cuáles no. Lo interesante en este caso es que el error en este fichero no apuntaba al servicio de SQL Browser sino al componente MSXML 6.0 (el motor XML de Microsoft):

Detailed results:
Feature:                       Servicios de Motor de base de datos
Status:                        Error: consulte los registros para obtener detalles
MSI status:                    Error: vea los detalles a continuación
MSI error code:                0x5EBE5729
MSI log file location:         C:\Archivos de programa\Microsoft SQL Server\100\Setup Bootstrap\Log\20090514_170659\Msxml6_Cpu32_1.log

Buscando dentro del fichero indicado se podía ver los siguiente (Msxml6_Cpu32_1.log):

MSI (s) (30:58) [17:22:37:661]: Note: 1: 1708
MSI (s) (30:58) [17:22:37:661]: Producto: MSXML 6.0 Parser (KB933579) -- Error en la instalación.

MSI (s) (30:58) [17:22:37:661]: Windows Installer instaló el producto. Nombre del producto: MSXML 6.0 Parser (KB933579). Versión del producto: 6.10.1200.0. Idioma del producto: 3082. Resultado de la instalación: 1603.

MSI (s) (30:58) [17:22:37:661]: Cleaning up uninstalled install packages, if any exist
MSI (s) (30:58) [17:22:37:661]: MainEngineThread is returning 1603

Estaba claro por tanto que el servicio SQL Browser no era el único componente que fallaba durante el proceso de instalación, el motor de Microsoft para XML 6.0 estaba también fallando. Observando los tiempos de los ficheros Detail.txt y Msxml6_Cpu32_1.log se podía comprobar además que este último mostraba el error antes; en otras palabras, el error de instalación de MSXML estaba teniendo lugar antes del error de instalación de SQL Browser. Volví de nuevo al fichero Detail.txt para confirmar este punto:

2009-05-14 17:22:36 Slp: ----------------------------------------------------------------------
2009-05-14 17:22:36 Slp: Running Action: Install_Msxml6_Cpu32_Action
2009-05-14 17:22:36 Slp: Target package: "D:\x86\setup\x86\msxml6.msi"
2009-05-14 17:22:37 Slp: InstallPackage: MsiInstallProduct returned the result code 1603.
2009-05-14 17:22:38 Slp: Sco: Attempting to write hklm registry key SOFTWARE\Microsoft\Microsoft SQL Server to file C:\Archivos de programa\Microsoft SQL Server\100\Setup Bootstrap\Log\20090514_170659\Registry_SOFTWARE_Microsoft_Microsoft SQL Server.reg_
2009-05-14 17:22:38 Slp: Sco: Attempting to write hklm registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall to file C:\Archivos de programa\Microsoft SQL Server\100\Setup Bootstrap\Log\20090514_170659\Registry_SOFTWARE_Microsoft_Windows_CurrentVersion_Uninstall.reg_
2009-05-14 17:22:38 Slp: Sco: Attempting to write hklm registry key SOFTWARE\Microsoft\MSSQLServer to file C:\Archivos de programa\Microsoft SQL Server\100\Setup Bootstrap\Log\20090514_170659\Registry_SOFTWARE_Microsoft_MSSQLServer.reg_
2009-05-14 17:22:43 Slp:
2009-05-14 17:22:43 Slp: Watson bucket for Msi based failure has been created
2009-05-14 17:22:43 Slp: No retry-able MSI return code detected.
2009-05-14 17:22:43 Slp: Checkpoint: INSTALL_MSXML6_CPU32_ACTION
2009-05-14 17:22:43 Slp: Completed Action: Install_Msxml6_Cpu32_Action, returned False
2009-05-14 17:22:43 Slp: Error: Action "Install_Msxml6_Cpu32_Action" failed during execution.

Al revisar la información de "Agregar o Quitar Programas" en el Panel de Control de Widnows podía ver que el componente MSXML 6.0 se encontraba de hecho instalado. Este es un componente compartido instalado por SQL Server 2008 pero en mi caso el cliente no estaba seguro de si este estaba ya allí antes de la instalación de SQL Server. Decidí desinstalar este componente usando el propio "Agreagar o Quitar Progamas" y lanzar la instalación de SQL Server 2008 de nuevo. Esta vez la instalación se completó sin errores.

En este caso el error inicial de SQL Server Browser era confuso al ser el primer error que se mostraba en la interfaz gráfica. Solo mirando en los ficheros de registro de instalación de SQL Server pudimos comprobar que existía un problema anterior en la instalación de los componentes MSXML 6.0.

Otra posible forma de descubrir este error es mediante el fichero de registro del Bucket de Watson que se genera al producirse un error durante el proceso de instalación y que se encuentra en el mismo directorio de Log:

En nuestro caso el contenido de este fichero era:

Watson bucket data:
Bucket param 1: 10.0.1600.22
Bucket param 2: 6.10.1200.0
Bucket param 3: msxml6.msi
Bucket param 4: 0x2D2816FE
Bucket param 5: 0x5EBE5729
Bucket param 6: Install_Msxml6_Cpu32_Action
Bucket param 7:
Bucket param 8:
Bucket param 9:
Bucket param 10:

He revisado las notas referentes al SP1 para SQL Server 2008 y este problema parece estar resuelto en este Paquete de Servicio de forma que otra opción para evitar este problema sería la de instalar una versión de SQL Server 2008 con el Service Pack ya integrado (esto es lo que se conoce en Inglés como Slipstreaming). Esta funcionalidad es nueva en SQL Server 2008 y permite a los administradores de bases de datos integrar Paquetes de Servicio en los medios de intalación reduciendo los tiempos de despliegue y evitando problemas conocidos.

- Jorge Pérez, Microsoft Customer Support Services