miércoles, 16 de diciembre de 2009

SharePoint 2010 en una instancia de SQL Server con nombre

Lo que voy a explicar hoy no sólo aplica a SharePoint 2010, sinó que es válido para otras versiones de SharePoint e incluso para otros productos que se comuniquen con SQL Server. De todas formas, y pese a que llevo años trabajando con SharePoint, no ha sido hasta hoy que he tenido que pelearme con lo que viene a continuación.

Voy a empezar por la conclusión: por defecto, cuando trabajas con instancias de SQL Server con nombre -para aquellos que no estén familiarizados con este concepto, las instancias con nombre son aquellas de tipo similar a SERVIDOR\instancia - el sistema no utiliza el puerto por defecto (1433) para comunicarse con el exterior. Por defecto utiliza un puerto dinámico. Esto, amigos míos, puede resultar una pesadilla cuando lo mezclamos con la palabra prohibida para todo desarrollador que se precie: ¡¡¡Firewall!!!

A continuación, un disclaimer (traducción: mis excusas para no haber llegado a una conclusión como ésta en el pasado). Normalmente no utilizo instancias con nombre, sino que uso la instancia por defecto para realizar instalaciones de SharePoint. Cuando se utiliza una instalación stand-alone tenemos que usar forzosamente una de estas instancias pero, evidentemente, en esos casos nunca tendremos problemas de firewall ya que todo estará instalado en la misma máquina. (Además, los desarrolladores no sabemos de puertos, firewalls ni usuarios de servicio :P)

Y ahora vamos a ver lo que me he encontrado hoy, y entenderemos por qué relaciono este post con SharePoint 2010. Después de haber instalado unas cuantas veces SharePoint 2010 para jugar un poco con él y para hacer alguna que otra demo hoy me he dispuesto a instalarlo en mi organización para empezar a trabajar en serio con el producto y empezar a plantear proyectos reales. Para realizar la instalación sigo, como de costumbre, los consejos de: http://blogs.msdn.com/opal/archive/2009/11/16/installation-notice-for-sharepoint-2010-public-beta.aspx y de http://technet.microsoft.com/en-us/library/ee805948(office.14).aspx. Todo parece ir bien pero, cuál es mi sorpresa cuando recibo la inesperada visita del protagonista de este post. Lo llamaré actor secundario Bob porque quiere permanecer en el anonimato. El caso es que me llama y me enseña la lista de entre 10 y 15 bases de datos de nombre variopinto que ha generado la instalación del producto. Esto tene una explicación y tiene que ver con las aplicaciones de servicio de SharePoint 2010, pero esto lo dejaré para otro post. El caso es que, como es de suponer, no es una situación cómoda por lo complejo que puede resultar su mantenimiento. Tras sopesar las diferentes posibilidades, decidimos crear una instancia de SQL Server dedicada para la instalación de SharePoint. Se crea la instancia, se actualiza a la versión SP1 CU2 y se procede a la re-ejecución del asistente de SharePoint, y aquí es donde vienen los problemas, dado que no hay manera de conseguir que la instancia de SQL Server sea visible para el asistente. No hay manera, claro, hasta que acudo a la segunda solución más utilizada del mundo de la informatica después de reiniciar la máquina: parar el firewall. Tras unos segundos de esperanza, la mirada del actor secundario Bob me hace volver a la realidad, ya que no podemos ir sin firewall por la vida. Vuelve la desesperación. Pero aquí es donde el actor secundario Bob se gana a pulso el ser el protagonista de este post, cogiendo el control de las máquinas y resolviendo el problema de una manera elegante. Incluso se permite el lujo de ofrecerme dos posibles soluciones cada cual más documentada. Ahí van:

1. Configurar la instancia de la base de datos para utilizar un puerto estático:
http://msdn.microsoft.com/en-us/library/ms345327.aspx

2. Configurar el firewall del servidor de SQL para que permita el acceso al programa en sí:
http://msdn.microsoft.com/en-us/library/cc646023.aspx#BKMK_dynamic_ports

Bueno, después de tomar una de estas dos alternativas (en mi caso la segunda) todo funcionó correctamente. Gracias actor secundario Bob, estás hecho todo un IT Pro (traducción: chispas).

5 comentarios:

Actor secundario Bob dijo...

Mira bonita, cuando vuelva a la oficina te vas a enterar! :-)

Y otro día te obligaré ('chispas' mode) a cambiar los nombres de esas BD, a ver si tan crack que eres las sabes cambiar y dejamos de tener GUIDs y cosas raras en la lista del SQL Server.

Ah, y gracias al 'actor terciario Landres', por avisarme de este post (mira que es cizañero!).

Un saludo.

David Martos dijo...

Tio, ahora la gente atará cabos. Saben que eres alguien que tiene que volver a la oficina (vamos, que ahora no estás) y que me tienes amenazado ;)

Lo de cambiar el nombre a las BBDD sería la solución fácil y nosotros preferimos las soluciones elegantes ;)

Bob... who's Bob? dijo...

¡Rajao!

Anónimo dijo...

Espero que Bob haya cambiado la pulsera de muñeca después de escribir su comentario...

Landres dijo...

Ostia, actor terciario y cizañero, creo que es lo mas bonito que me han dicho en un blog :D.

En cualquier caso, el nombre de las bases de datos no es ta importante, porque como todos sabemos seguro que estara perfectamente documentado en alguna parte :).