Error occurred in deployment step 'Recycle IIS Application Pool': The local SharePoint server is not available

Estos días he tenido que pelearme un poco con un servidor MSS2010 de desarrollo debido al error que da el título a este artículo, os pongo en antecedentes:

Situación inicial

Estamos desarrollando una WebPart para MSS 2010, nada fuera de lo común, una WebPart sencillita, cuyos detalles además no vienen al caso.

Por motivos que tampoco vienen al caso, el desarrollo se estaba realizando con un usuario ‘genérico’ mediante escritorio remoto. Todo funcionando de lujo hasta que otro compañero necesita conectar en remoto también con ese usuario, como ya sabréis no puede haber (creo) dos conexiones remotas distintas con el mismo usuario (si se puede ya me avisaréis).

El caso es que ya no se puede desarrollar con el dichoso usuario ‘genérico’… Ningún problema, inicio el escritorio con mi usuario, mapeo el código de TFS y a funcionar…

El problema

El proyecto se abre sin problema, compila de lujo (como era esperado) pero (siempre hay un pero) al ir a realizar el despliegue de la Web Part, de repente mensaje de error:

y en los detalles del error en la ventana de “Error List”:

Ay ay ay, uy uy uy…

Menos mal que nos queda Google… Revisando por ahí posibles soluciones al problema, resulta que el error viene (lógico por otra parte) por un problema de permisos de mi usuario en la infraestructura Sharepoint del servidor de desarrollo.

La solución

Gracias al siguiente artículo, el problema se soluciona utilizando el comando Add-SPShellAdmin.

¿Cómo lo utilizamos para solucionar el problema?

Iniciamos una consola de administración de Sharepoint y ejecutamos el comando:

Add-SPShellAdmin dominio\usuario

Puede producirse un error de conexión con el servidor local (el mismo que nos da desde Visual Studio) si se produce no nos queda otra que pedir que nos ejecuten el comando con el usuario ‘genérico’

Una vez ejecutado el comando, al intentar realizar el despliegue, puede producirse el siguiente error:

Si revisamos el visor de sucesos del servidor, podemos ver que se trata de un acceso denegado con la Base de Datos de contenido del servidor Sharepoint. Para solucionar este problema, tenemos que utilizar el mismo comando anterior, especificando el id de la Base de Datos de Contenido que nos indica en el visor de sucesos.

Averiguar el ID de la Base de Datos de contenido

Ejecutamos el siguiente comando PowerShell:

Get-SPDatabase | Select Name, Id

Localizamos el nombre que hemos obtenido en el Visor de Sucesos, y apuntamos el Id, que utilizaremos en la siguiente instrucción:

Add-SPShellAdmin dominio\usuario –database Id

 

y con esto, a funcionar!!!

Cómo activar una aplicación heredada con Lync 2010

O cómo pasar una aplicación integrada con OCS 2007 a LYNC 2010 sin morir en el intento

 

Situación inicial

Partimos de una aplicación desarrollada con el UCMA 2.0 de OCS que, básicamente registra un nuevo usuario o SIP en el servicio de OCS y permite establecer conversaciones con él, lo que viene a ser un BOT de toda la vida.

En este artículo no vamos a ver código como tal, ya que la aplicación original no sufre ningún cambio a la hora de ‘migrarla’ a un entorno de LYNC 2010. Como ya podemos imaginarnos, lo más correcto hubiera sido migrar la propia aplicación al UCMA 3.0, pero en esta ocasión no disponemos del tiempo necesario, así que ¿Qué hacemos?

Como explicación inicial, indicar que la aplicación que queremos ‘reconfigurar’ está funcionando correctamente en un entorno OCS 2007, y su configuración inicial se realizó con la herramienta “Application Provisioner” (enlace)

 

Primer intento

Nuestra aplicación está correctamente aprovisionada en el OCS, y dado que nuestra infraestructura lo permite, la primera intención es simplemente modificar el archivo de configuración para apuntar al nuevo servidor de LYNC en lugar de al servidor original. Resultado, no funciona; el endpoint establece correctamente la conexión, la cuenta en el cliente LYNC aparece como disponible, pero al iniciar una conversación, se produce un error.

Revisando el visor de eventos, encontramos el siguiente error:

 

Segundo intento

A continuación intentamos modificar el host de LYNC (“OCS Pool Fqdn”) mediante la herramienta “Application Provisioner”. Resultado, no se puede, hay que generar un Application Pool nuevo. De acuerdo, si no queda más remedio, creamos uno nuevo, con las mismas características que el anterior, pero utilizando el nuevo Host de LYNC.

Ojo, porque si queremos mantener el servidor de aplicaciones, tendremos que eliminar el Application Pool anterior, ya que de lo contrario nos encontraremos con es siguiente error:

Una vez creado el nuevo pool, actualizamos en el archivo de configuración de la aplicación el “GRUU” y lanzamos la prueba. Resultado, no funciona; el cliente LYNC vuelve a mostrar el mismo error de antes, y en el visor de eventos, de nuevo el mismo error.

 

Replanteamiento

Si no puedes con el enemigo, únete a él. En este momento, tenemos una aplicación que no funciona en ningún entorno, así que hacemos marcha atrás, y volvemos a la situación inicial.

Entonces, ¿qué hacemos? tras mucho mirar y remirar por ahí, acabamos llegando a la conclusión (por otra parte lógica) de que el mecanismo de aprovisionamiento para OCS NO es compatible con LYNC y que la única manera de realizar la “reconfiguración” va a ser pelearnos con Powershell en el servidor LYNC.

 

Al turrón

Con la aplicación aprovisionada en el servidor OCS 2007, tenemos que ejecutar unos comandos de Powershell en el servidor LYNC, para lo que iniciamos la consola de administración de LYNC (“Lync Server Management Shell”) que no deja de ser una consola de Powershell (recomendado hacerlo como Administrador) y empezamos a ‘picar’ instrucciones:

1. “Merge-CsLegacyTopology -TopologyXmlFileName newtopology.xml”
2. “Publish-CsTopology -FileName newtopology.xml”
3. “Enable-CsTopology”
   Estas instrucciones recrean el pool original de OCS 2007 en la topología del servidor LYNC.
4. “Move-CsApplicationEndpoint {identity] -TargetApplicationPool {fqdn} –Force”
   Esta instrucción mueve los contactos al nuevo pool, con lo que en principio ya estaríamos listos.

¿Cómo averiguamos el “{identity}”?

Ejecutamos el comando “Get-CsApplicationEndpoint” y en los resultados buscamos nuestra aplicación y copiamos el valor de la propiedad “Identity”

 

Fin de la historia