viernes, 1 de abril de 2011

The extended protection settings configured on IIS do not match the settings configured on the transport

Hoy me he encontrado con un extraño error en una instalación de SharePoint 2010 que hacía que algunos servicios no se iniciaran correctamente y que fuera imposible conectar con las colecciones de sitios con SharePoint Designer. Tras revisar el visor de sucesos y las trazas de SharePoint topé con la siguiente excepción:

WebHost failed to process a request.

Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/12036987

Exception: System.ServiceModel.ServiceActivationException: The service '/_vti_bin/client.svc' cannot be activated due to an exception during compilation. The exception message is: The extended protection settings configured on IIS do not match the settings configured on the transport. See inner exception for details.. ---> System.NotSupportedException: The extended protection settings configured on IIS do not match the settings configured on the transport. See inner exception for details. ---> System.InvalidOperationException: The ExtendedProtectionPolicy.PolicyEnforcement values do not match. One policy has a value of WhenSupported, while the other has a value of Never. These values must match exactly.

Tras investigar un rato, encontré información referente a la configuración de IIS, más concretamente, a su configuración de autenticación. No quiero entrar demasiado en detalle, primero porque no soy un experto en la materia, y segundo porque si habéis llegado aquí posiblemente estéis buscando una solución y no una clase magistral de configuración de IIS.

Para solucionar el problema, en cada una de las aplicaciones web de SharePoint que os esté generando la excepción anteriormente mencionada, acceder a la configuración de autenticación de IIS.

image

Una vez allí deberíais tener habilitado, almenos, autenticación windows. Si entráis en la configuración avanzada, tal y como muestra la figura, accederéis a la configuración de protección extendida.

image

En mi caso tenía configurada la protección extendida en modo Accept. Hacer el cambio a Off solucionó el problema.

image

Nota importante: en el caso que me ocupa me encontraba en un entorno de pruebas y, por lo tanto, realicé este cambio sin investigar a fondo las causas que modificaron este parámetro ni las consecuencias de hacer la variación correspondiente. Si tenéis que hacer esto en un entorno desplegado en producción, os recomiendo que vosotros sí lo hagáis.

lunes, 28 de marzo de 2011

Instalar Lync Server 2010 en WS2008R2 SP1

En un artículo anterior expliqué como instalar Lync Server 2010 sobre Windows Server 2008 R2. Tras algunos problemas, sobretodo motivados por incompatibilidades con SQL Server 2008 R2 y por el uso del usuario administrador de dominio para instalar la plataforma, todo comenzó a funcionar como la seda. Tanto fue así que me animé a hacer una nueva instalación, pero esta vez en una granja completa y usando las cuentas de usuario recomendadas por la documentación. Al hacerlo de esta manera me he encontrado con algunas diferencias, todas ellas debidamente indicadas en la documentación del producto y referentes, por ejemplo, a los permisos que necesita el usuario que se usa para la instalación de Lync Server 2010. Ha habido un detalle, eso sí, que tuve que deducirlo yo, y que está relacionado con la instalación sobre Windows Server 2008R2 SP1.

Si sigues el proceso de instalación, a la hora de ejecutar el segundo paso (Setup or remove Lync Server components) del apartado Install or update Lync Server System, nos encontraremos con un error similar al siguiente:

Executing external command: C:\Windows\system32\dism.exe /online /norestart /add-package /packagepath:C:\Windows\servicing\Packages\Microsoft-Windows-Media-Format-Package~31bf3856ad364e35~amd64~~6.1.7600.16385.mum /ignorecheck MM/DD/YYYY HH:MM:SS AM Installation result: -2146762496 MM/DD/YYYY HH:MM:SS AM Error: Prerequisite installation failed: Wmf2008R2

El caso es que WS2008R2 SP1 viene con una versión más nueva del paquete en cuestión y, si navegamos a la carpeta C:\Windows\servicing\Packages veremos que el fichero que estamos buscando es, en realidad:

Microsoft-Windows-Media-Format-Package~31bf3856ad364e35~amd64~~6.1.7601.17514

Al parecer, si instalas la característica Desktop experience, el problema desaparece. No obstante hay una solución más simple. Basta con ejecutar el comando que aparece en la traza cambiando el nombre del paquete a instalar:

C:\Windows\servicing\Packages\Microsoft-Windows-Media-Format-Package~31bf3856ad364e35~amd64~~6.1.7601.17514.mum /ignorecheck

Después de ejecutar el comando anterior será necesario reiniciar el servidor antes de continuar con el proceso de instalación.

Por cierto, para vuestra tranquilidad, antes de ejecutar el comando anterior busqué información acerca de asunto para evitar problemas mayores. Aquí tenéis la página que confirma la solución.