GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Configurar un Cluster NLB de Microsoft Dynamics CRM 4.0 sobre Windows Server 2008 R2 e IIS7.5: Kerberos, IIS7.5, Reporting Services y SQL Server


Este artículo describe la forma correcta de configurar la Autenticación Integrada y la Delegación de Kerberos en una instalación de Alta Disponibilidad (Cluster NLB) de Microsoft Dynamics CRM 4.0 sobre Windows Server 2008 R2 (IIS7.5) utilizando una Granja independiente de Reporting Services 2008 R2. Esta compleja configuración de Kerberos, es la causante de errores conocidos como Error. An error has occurred, o también del error Reporting Error. The report cannot be displayed, y también del error Not Authorized. HTTP Error 401. The requested resource requires user authentication, todos ellos relacionados con CRM, IIS, Reporting Services y Kerberos.

Hacía mucho tiempo que no me costaba tanto esfuerzo realizar una configuración. Lo cachondo, no es eso como tal, sino el hecho de haber estado preparando con tiempo una instalación/configuración, revisando todo tipo de documentación técnica (White Papers, KBs de Microsoft, artículos de TechNet, entradas de Blogs, preguntas y respuestas en foros, eBooks, etc.), y cuando estás más que preparado para realizar la implementación (o eso crees tú), dispones de todos los recursos necesarios (máquinas ya instaladas, cuentas de usuario creadas, direcciones IP asignadas y configuradas, descargado todo el software y sus actualizaciones posteriores, montados los Cluster NLBs, etc.) y te has leído todo Internet y parte del Google, vas y te das con to lo gordo. En cualquier caso, mola (a la par que duele), ya que es con estos brownies con los que más se aprende.

Una vez más, el causante de mi desgracia es Kerberos (ej: recordemos la guerra de la configuración Kerberos con MOSS y Analysis Services, entre otras crisis), bueno, más exactamente Kerberos con CRM 4.0 sobre IIS7.5, Reporting Services 2008 R2 y SQL Server 2008 R2. Me explico.

Descripción del Escenario

Partimos de una instalación de Microsoft Dynamics CRM 4.0 sobre Windows Server 2008 R2. Esta instalación se ha realizado sobre dos Máquinas Virtuales, instalándose en ambas Máquinas Virtuales ambos Roles de CRM (el Application Server Role y también el Platform Server Role). Sobre dichas Máquinas Virtuales se ha configurado un Cluster NLB de Windows Server 2008 R2. Téngase en cuenta, que al tratarse de Windows Server 2008 R2, hemos tenido que realizar la instalación de Microsoft Dynamics CRM 4.0 especificando como cuenta de servicio la cuenta de Network Service, en lugar de una cuenta de dominio. Esto es un Workaround, que implica que después de la instalación (y esto es una de las cosas que veremos en este artículo más adelante) será necesario modificar la cuenta de servicio utilizada por el Pool de Aplicaciones de IIS.

El servidor de base de datos de CRM es una máquina independiente, que ejecuta SQL Server 2008 R2 sobre Windows Server 2008 R2. También se han montado dos Máquinas Virtuales independientes, para ejecutar Reporting Services 2008 R2 sobre un Cluster NLB de Windows Server 2008 R2. Estas máquina de Reporting Services 2008 R2, están instaladas y configuradas tal cual, es decir, está Reporting Services configurado en las dos máquinas, pero no se ha realizado ninguna configuración adicional, por ejemplo, relativa a Kerberos.

Descripción de los Errores

En una implementación de Microsoft Dynamics CRM 4.0 como la descrita, utilizando un Cluster NLB sólo para CRM, otro Cluster NLB independiente sólo para Reporting Services, y otra máquina independiente (o bien, un Failover Cluster) sólo para SQL Server, al intentar acceder a alguno de los informes de CRM (que a fin de cuentas, son informes de Reporting Services), se mostrará el siguiente error:

Error. An error has occurred. Try this action again. If the problem continues, check the Microsoft Dynamics CRM Community for solutions or contact your organization’s Microsoft Dynamics CRM Administrator. Finally, you can contact Microsoft Support.

A continuación se muestra una pantalla capturada de dicho error.

Error. An error has occurred. Try this action again. If the problem continues, check the Microsoft Dynamics CRM Community for solutions or contact your organization’s Microsoft Dynamics CRM Administrator. Finally, you can contact Microsoft Support.

Este genérico error de CRM al acceder a un informe de Reporting Services (An error has ocurred), se trata de un error típico de configuración de Kerberos. Para solucionarlo, y para dejar configurado Microsoft CRM 4.0 correctamente tras la instalación, en principio tan sólo es necesario seguir varios pasos:

  • Por un lado configurar el Pool de Aplicaciones de IIS con una cuenta de usuario de Directorio Activo, con todo lo que implica (ej: pertenencia a grupos locales, pertenencia a grupos de Directorio Activo), como se describe en la KB de Microsoft Support for Microsoft Dynamics CRM 4.0 on Windows Server 2008-based computers.
  • Por otro lado, configurar los Bindings (Host Header) deseados en IIS del Site de Microsoft CRM 4.0, para así poder acceder correctamente con el nombre compartido deseado, a través del NLB. Esto también implica la correspondiente alta de registros en DNS.
  • Por último es necesario configurar la Autenticación Integrada y Delegación de Kerberos para la Aplicación Web de CRM en IIS, así como actualizar manualmente la la base de datos de CRM especificando la URL compartida para acceder a CRM. Estos pasos están descritos en la Installation Guide de Microsoft Dynamics CRM 4.0 (es decir, en Microsoft TechNet).

Sin embargo, tras realizar todas estas tareas, al menos con Windows Server 2008 R2 (es decir, IIS7.5), nos encontraremos con el siguiente mensaje de error, y aquí ya sí que estamos jodidos (o esa fue mi sensación, que luego no es para tanto):

Not Authorized. HTTP Error 401. The requested resource requires user authentication.

A continuación se muestra una pantalla capturada del mismo:

Not Authorized. HTTP Error 401. The requested resource requires user authentication.

Por suerte, conseguiremos solucionar este error (como veremos, una configuración específica de IIS7.5, que imagino ocurrirá también con IIS7), sin embargo, tras ello, al intentar acceder a los informes de Reporting Services desde Microsoft CRM, nos encontraremos un nuevo error.

Reporting Error. The report cannot be displayed.

A continuación se muestra una pantalla capturada del mismo:

Reporting Error. The report cannot be displayed.

De hecho, si intentamos acceder a los informes Reporting Services de CRM directamente a través del propio Reporting Services (es decir, sin acceder a través de CRM), nos encontraremos que no podemos acceder correctamente al Report. Creo que el error que se mostraba era el siguiente:

An error has occurred during report processing. (rsProcessingAborted). Cannot create a connection to data source 'CRM'. (rsErrorOpeningConnection)

Es más, si desde Reporting Services editamos el Origen de Datos de CRM (tendremos que mostrar la Vista Detallada), y realizamos un test de conexión, se mostrará el siguiente error:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

Finalmente, conseguiremos solucionar también este error, quedando nuestra infraestructura de Microsoft Dynamics CRM 4.0 funcionando correctamente en Alta Disponibilidad y con la Autenticación de Windows y la Delegación de Kerberos correctamente configurada para Microsoft CRM 4.0, Reporting Services 2008 R2 y SQL Server 2008 R2.

Desde luego para mí, no ha sido nada fácil, y de hecho algunos clientes, incapaces de poder realizar esta compleja configuración de Kerberos, finalmente como Workaround deciden implementar el CRM Connector for SQL Server Reporting Services para salir del apuro.

A continuación, entramos en el detalle de toda la configuración realizada, y los diferentes errores encontrados.

Cambiar la cuenta del Pool de Aplicaciones de IIS7.5

Para realizar esta configuración nos hemos basado en la siguiente KB de Microsoft, ya que se trata de una instalación de Microsoft Dynamics CRM 4.0 sobre Windows Server 2008 R2: Microsoft Support for Microsoft Dynamics CRM 4.0 on Windows Server 2008-based computers.

Esto implica, que realizamos la instalación de Microsoft Dynamics CRM especificando la cuenta de Network Service, que ahora deberemos modificar por una cuenta de Directorio Activo. Empezamos.

En la herramienta administrativa IIS Manager, mostraremos los Application Pools de IIS, y seguidamente seleccionaremos la opción Advanced Settings del menú contextual del Application Pool correspondiente al Microsoft Dynamics CRM (se denomina por defecto CRMAppPool, como se muestra en la siguiente pantalla capturada).

En la herramienta administrativa IIS Manager, mostraremos los Application Pools de IIS, y seguidamente seleccionaremos la opción Advanced Settings del menú contextual del Application Pool correspondiente al Microsoft Dynamics CRM (se denomina por defecto CRMAppPool, como se muestra en la siguiente pantalla capturada)

En el diálogo Advanced Settings, click en el botón con los tres puntitos, correspondiente a la opción Identity.

En el diálogo Advanced Settings, click en el botón con los tres puntitos, correspondiente a la opción Identity

Se mostrará el diálogo Application Pool Identity, en el cual, deberemos seleccionar la opción Custom account, y utilizar el botón Set para especificar las credenciales de la cuenta de Directorio Activo desea para ejecutar el Pool de Aplicaciones de Microsoft CRM. Click OK, y seguidamente click OK en el diálogo Advanced Settings.

Se mostrará el diálogo Application Pool Identity, en el cual, deberemos seleccionar la opción Custom account, y utilizar el botón Set para especificar las credenciales de la cuenta de Directorio Activo desea para ejecutar el Pool de Aplicaciones de Microsoft CRM. Click OK, y seguidamente click OK en el diálogo Advanced Settings

Realizado esto, habremos modificar el Application Pool de Microsoft Dynamics CRM para ejecutarse utilizando la identidad de una cuenta de Directorio Activo. Dado que estamos hablando de una Granja de servidores Microsoft CRM (es decir, un Cluster NLB formado por varias máquinas), deberemos seguir estos pasos en todas las máquinas de la Granja (esto esto, en todos los nodos del Cluster NLB de CRM).

Para continuar, a nivel de Directorio Activo, deberemos abrir la consola de Active Directory Users and Computers (ADUC) que encontraremos por defecto instalada en cualquier Controlador de Dominio, editar la cuenta de usuario de Directorio Activo utilizada como identidad del Pool de Aplicaciones de CRM (en nuestro caso, la cuenta GUILLESQL\CRM4Svc), y hacer a esta cuenta miembro de los grupos PrivUserGroup y SQLAccessGroup de la correspondiente instalación de Microsoft Dynamics CRM, como se muestra en la siguiente pantalla capturada.

A nivel de Directorio Activo, deberemos abrir la consola de Active Directory Users and Computers (ADUC) que encontraremos por defecto instalada en cualquier Controlador de Dominio, editar la cuenta de usuario de Directorio Activo utilizada como identidad del Pool de Aplicaciones de CRM (en nuestro caso, la cuenta GUILLESQL\CRM4Svc), y hacer a esta cuenta miembro de los grupos PrivUserGroup y SQLAccessGroup de la correspondiente instalación de Microsoft Dynamics CRM

Para continuar, es necesario agregar la cuenta de usuario de Directorio Activo utilizada como identidad del Pool de Aplicaciones de CRM (en nuestro caso, la cuenta GUILLESQL\CRM4Svc), a los grupos locales IIS_IUSRS y CRM_WPG de cada una de las máquinas de la Granja de Microsoft Dynamics CRM (téngase en cuenta, que sí montásemos Microsoft CRM sobre un Controlador de Dominio, estos grupos no aparecerían como Grupos Locales, existiendo en su lugar en la carpetas BUILTIN y USERS de Directorio Activo).

Configurar los Bindings (Host Header) del Site de CRM en IIS7.5

En la instalación realizada de Microsoft Dynamics CRM 4.0, se seleccionó la opción de Create new Web Site, utilizando el puerto por defecto de Microsoft CRM 4.0 (es decir, el puerto 5555).

Dado que necesitamos poder acceder a la Aplicación Web de CRM utilizando un nombre DNS compartido (es decir, a través del NLB, en nuestro caso, http://vcrm00.guillesql.local) y utilizando el puerto por defecto para HTTP (es decir, el puerto 80, en vez del puerto 5555), es necesario modificar en los Bindings del Site en IIS7, en los dos Nodos del NLB (es decir, en las dos máquinas que ejecutan la Aplicación Web de CRM4).

Para ello abriremos la herramienta administrativa de IIS Manager, desplegaremos hasta mostrar el Sitio Web de Microsoft CRM, y seleccionaremos la opción Edit Bindings del menú contextual.

Abriremos la herramienta administrativa de IIS Manager, desplegaremos hasta mostrar el Sitio Web de Microsoft CRM, y seleccionaremos la opción Edit Bindings del menú contextual

En el diálogo Site Bindings, click en el botón Add para añadir un nuevo Binding.

En el diálogo Site Bindings, click en el botón Add para añadir un nuevo Binding

En el diálogo Add Site Binding, seleccionaremos el protocolo deseado (en nuestro caso HTTP), opcionalmente la dirección IP (en nuestro caso All Unassigned), el puerto (en nuestro caso el 80), y el Host Name (en nuestro caso vcrm00.guillesql.local). Click OK para continuar.

En el diálogo Add Site Binding, seleccionaremos el protocolo deseado (en nuestro caso HTTP), opcionalmente la dirección IP (en nuestro caso All Unassigned), el puerto (en nuestro caso el 80), y el Host Name (en nuestro caso vcrm00.guillesql.local). Click OK para continuar

Si deseamos añadir otros Bindings adicionales (ej: tener un Binging para el nombre corto, y otro binding para el nombre largo, que es lo que hicimos en este laboratorio), repetiremos estos pasos. De lo contrario, click Close.

Configurar Kerberos y los SPN de Directorio Activo para Microsoft Dynamics CRM y Reporting Services

Ya hemos hablado en ocasiones anteriores de las configuraciones necesarias para hacer funcionar la Autenticación Integrada y Delegación de Kerberos en IIS6. En esta ocasión vamos a realizar lo propio, pero para el IIS7.5 de Windows Server 2008 R2 y también para Reporting Services. Los pasos a realizar son:

Activar la Autenticación Integrada en el IIS7.5. Abrir la Herramienta Administrativa de IIS Manager, y utilizar la opción Authentication del Sitio Web de CRM. Deben estar sólo activados los elementos Windows Authentication y ASP.NET Impersonation.

Configurar en Microsoft Internet Explorer (es decir, en los equipos clientes) la zona de seguridad de Local Intranet para incluir el nombre DNS que deseamos utilizar para acceder a la Aplicación Web de Microsoft Dynamics CRM 4.0 (si no estuviese incluido ya en dicha zona), y además, modificar la configuración de la zona activando la opción de "Automatic logon with current user name and password" si no estuviese así configurada. Esta configuración se debe realizar sobre todos los equipos clientes, por lo cual, resulta de utilidad el uso de Directivas de Grupo (es decir, Políticas de Directorio Activo), o alguna otra forma de automatización para aplicar esta configuración de forma masiva.

Habilitar la Delegación de Kerberos en la cuenta de usuario utilizada en el Application Pool del IIS (en nuestro caso, la cuenta GUILLESQL\CRM4Svc). Esta tarea se hace con la Herramienta Administrativa de Active Directory Users and Computers (ADUC), en las Propiedades de la cuenta de usuario (opción Account is trusted for delegation).

Habilitar la Delegación de Kerberos en la cuenta de usuario utilizada en el Application Pool del IIS (en nuestro caso, la cuenta GUILLESQL\CRM4Svc), opción Account is trusted for delegation

Habilitar la Delegación de Kerberos en la cuenta de usuario utilizada por Reporting Services 2008 R2 (en nuestro caso, la cuenta GUILLESQL\SSRSSvc). Similar al paso anterior.

Habilitar la Delegación de Kerberos en la cuenta de usuario utilizada por Reporting Services 2008 R2 (en nuestro caso, la cuenta GUILLESQL\SSRSSvc), opción Account is trusted for delegation

Registrar los Service Principal Name (SPN) necesarios para acceder a la Aplicación Web de Microsoft Dynamics CRM y a Reporting Services, utilizando la utilidad setspn (también es posible utilizar otros métodos alternativos, como la herramienta administrativa ADSI Edit). En nuestro caso, estamos utilizando la cuenta GUILLESQL\CRM4Svc para ejecutar el Pool de Aplicaciones de IIS respondiendo a la URL http://vcrm00.guillesql.local, y del mismo modo estamos utilizando la cuenta GUILLESQL\SSRSSvc para ejecutar Reporting Services 2008 R2 respondiendo a la URL http://vrs00.guillesql.local. Como consecuencia, ejecutaremos los siguientes comando setspn:

  • setspn –A HTTP/vcrm00.guillesql.local GUILLESQL\CRM4Svc
  • setspn –A HTTP/vcrm00 GUILLESQL\CRM4Svc
  • setspn –A HTTP/vrs00.guillesql.local GUILLESQL\SSRSSvc
  • setspn –A HTTP/vrs00 GUILLESQL\SSRSSvc

Configurar la base de datos para referenciar la URL del NLB

Un paso adicional que tenemos que seguir es modificar la base de datos de CRM para especificar la URL que se utilizará para acceder a Microsoft Dynamics CRM, como queda documentado en la Installation Guide de Microsoft Dynamics CRM 4.0 en Microsoft TechNet. Para realizar este paso, utilizando la herramienta SQL Server Management Studio (SSMS), ejecutaremos las siguientes sentencias SQL sobre la base de datos de configuración de Microsoft Dynamics CRM 4.0 (es decir, la base de datos MSCRM_CONFIG), especificando el nombre DNS que deseamos utilizar para acceder a Microsoft CRM a través del NLB (es decir, el nombre compartido):

Update DeploymentProperties
set NVarCharColumn = 'vcrm00.guillesql.local'
where ColumnName = 'ADWebApplicationRootDomain'

Update DeploymentProperties
set NVarCharColumn = ' vcrm00.guillesql.local'
where ColumnName = 'ADsdkRootDomain'

Reinicio de las Máquinas Virtuales de Microsoft Dynamics CRM 4.0

Bueno, pues parece que ya hemos terminado. No está mal. Luego dirán que en Windows todo se instala en plan Siguiente-Siguiente, no te jode. Reiniciamos las máquinas de CRM y de Reporting Services (esto es una manía mía personal, cuando realizo configuraciones de Kerberos de este tipo, en teoría creo que no es necesario).

Tras el reinicio, comprobamos el acceso a Microsoft Dynamics CRM 4.0, y zas en toda la boca.

Not Authorized. HTTP Error 401. The requested resource requires user authentication

Ni con el nombre corto, ni con el nombre largo. No es posible acceder a Microsoft CRM 4.0. Siempre nos sale el mismo error: Not Authorized. HTTP Error 401. The requested resource requires user authentication.

Me volví loco. No fue trivial realizar toda la configuración que acabamos de aplicar, para que ahora nos salga este bonito mensaje de error. No hay nada que no se pueda conseguir con unas cuantas horas de Overtime, y tras unas cuentas pruebas y búsquedas por los Interneses, encontré la solución.

Al tratarse de un IIS7.5 (es decir, Windows Server 2008 R2, es necesario realizar una modificación en el fichero applicationHost.config que encontraremos en la ruta C:\Windows\System32\inetsrv\config. En particular, deberemos modificar la línea correspondiente a windowsAuthentication enabled="false", y cambiarla por windowsAuthentication enabled="true" useAppPoolCredentials="true", como se muestra en la siguiente pantalla capturada.

Al tratarse de un IIS7.5 (es decir, Windows Server 2008 R2, es necesario realizar una modificación en el fichero applicationHost.config que encontraremos en la ruta C:\Windows\System32\inetsrv\config. En particular, deberemos modificar la línea correspondiente a windowsAuthentication enabled=false, y cambiarla por windowsAuthentication enabled=true useAppPoolCredentials=true, como se muestra en la siguiente pantalla capturada

Seguidamente ejecutaremos un IISRESET desde una ventana de símbolo del sistema.

Seguidamente ejecutaremos un IISRESET desde una ventana de símbolo del sistema

Realizada esta modificación de ficheros e IISRESET en todos los servidores Microsoft CRM 4.0 de nuestra Granja, al volver a intentar acceder a Microsoft Dynamics CRM 4.0, por fin podremos acceder con éxito (genial, ya no se mostrará el mensaje de error Not Authorized. HTTP Error 401. The requested resource requires user authentication).

Al volver a intentar acceder a Microsoft Dynamics CRM 4.0, por fin podremos acceder con éxito

Vaya, parece que ya hemos acabado. Qué fácil, ¿no?

Sin embargo, al intentar acceder desde CRM a un informe de Reporting Services, se mostrará un nuevo mensaje de error:

Reporting Error. The report cannot be displayed.

Reporting Error. The report cannot be displayed

Los pelos como escarpias. Menos mal, que todo esto me lo estoy comiendo al montar un entorno de laboratorio. Si no lo hubiese hecho así, y estuviese en directo currándomelo en un Cliente, me lo estaría pasando cantidubi.

Investigando un poco más el error (Reporting Error. The report cannot be displayed), es fácil comprobar que si intentamos acceder a los informes Reporting Services de CRM directamente a través del propio Reporting Services (es decir, sin acceder a través de CRM), nos encontraremos que no podemos acceder correctamente al Report. Creo que el error que se mostraba era el siguiente (sorrys, no lo apunté, se me hizo una noche demasiado larga):

An error has occurred during report processing. (rsProcessingAborted). Cannot create a connection to data source 'CRM'. (rsErrorOpeningConnection)

Es más, si desde Reporting Services editamos el Origen de Datos de CRM (tendremos que mostrar la Vista Detallada), y realizamos un test de conexión, se mostrará el siguiente error:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

Vaya. Esto suena de nuevo a Kerberos. Por dios, esto es un no-parar.

Configurar la Autenticación Integrada y Delegación de Kerberos en Reporting Services

Continuando con mi sufrimiento, al revisarme la documentación de Reporting Services 2008 R2, en particular el How to: Configure Windows Authentication in Reporting Services, me doy cuenta, que para configurar la Autenticación Integrada y Delegación de Kerberos con Reporting Services 2008 R2 es necesario modificar el fichero rsReportServer.config, además de configurar los SPNs necesarios (realizado antes) y activar la delegación de Kerberos en la cuenta de usuario de Reporting Services (realizado antes, también). Fallo mío. Nunca antes había realizado una configuración de este tipo con Reporting Services, y no me había revisado esta documentación antes de la instalación.

Realizamos la configuración de los tipos de autenticación (AuthenticationTypes) en el fichero rsReportServer.config, añadiendo las líneas RSWindowsNegotiate y RSWindowsKerberos, como se muestra en la siguiente pantalla capturada.

Realizamos la configuración de los tipos de autenticación (AuthenticationTypes) en el fichero rsReportServer.config, añadiendo las líneas RSWindowsNegotiate y RSWindowsKerberos

También me revisamos el fichero Web.Config de Reporting Services, para comprobar que está configurado acorde a la anterior documentación de Reporting Services 2008 R2, y está todo OK. Ojo, que estas modificaciones y revisiones de los ficheros rsReportServer.config y Web.Config de Reporting Services, debemos realizarlas en todos los servidores Reporting de nuestra Granja.

Reiniciamos los servicios de Reporting Services de todas las máquinas de nuestra Granja.

Uff. Qué nervios. Ahora sí que tiene que funcionar. No veo el momento de volver a probarlo. Intento acceder a CRM con éxito, y tras esto, intento ejecutar un informe de Reporting Services desde CRM, y de nuevo, zas en toda la boca. Seguimos igual. Pero que bonito. Cuanto estoy aprendiendo esta noche de frustración, cuanto.

Sólo se me ocurre, que sea necesario configurar la Autenticación Integrada y Delegación de Kerberos en SQL Server. Lo intento.

Habilito la delegación de Kerberos en la cuenta de usuario utilizada por el servicio de SQL Server, de forma similar a como hicimos anteriormente con las cuentas de Reporting Services, y del Pool de Aplicaciones de CRM en IIS.

Configuramos los SPN necesarios para SQL Server, utilizando la herramienta administrativa setspn.exe, en particular, ejecutamos los siguientes dos comandos:

  • setspn –A MSSQLSvc/vsql08.guillesql.local:1433 GUILLESQL\SQLSvc
  • setspn –A MSSQLSvc/vsql08:1433 GUILLESQL\SQLSvc

Reiniciamos los servicios de SQL Server.

Intentamos de nuevo acceder a CRM, con éxito. Desde CRM ejecutamos un informe cualquiera de Reporting Services, voalá, POR FIN FUNCIONA.

Intentamos de nuevo acceder a CRM, con éxito. Desde CRM ejecutamos un informe cualquiera de Reporting Services, voalá, POR FIN FUNCIONA

Enlaces de interés

Antes de acabar, quería aprovechar para incluir algunas de las URLs que me han resultado de especial ayuda y/o de especial interés, como resultado de las múltiples búsquedas que he tenido que hacer a través de Google y Bing. He tenido la sensación de que toda esta información estaba algo dispersa y no resultaba fácil de encontrar, así que aquí van todas juntitas las URLs que más interesante me han parecido.

Y por último, por culturilla general y como recordatorio, quería aprovechar para incluir un resumen de los artículos aquí publicados en relación de la Autenticación Integrada y la Delegación de Kerberos.

Poco más por hoy. Como siempre, confío que la lectura resulte de ayuda, o al menos de interés.

 


Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Junio de 2017 (3)
Mayo de 2017 (1)
Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Copyright © 2007 GuilleSQL, todos los derechos reservados.