Segundo evento presencial del SUG.CAT

Desde SUG.CAT y con el apoyo de Microsoft Ibérica queremos continuar con las sesiones presenciales del Grupo de Usuarios de SharePoint de Catalunya con dos presentaciones de algunas de las características de SharePoint 2010 que más interés han despertado en la comunidad. En una de estas presentaciones os enseñaremos como podéis gestionar el ciclo de vida de las aplicaciones (ALM) en proyectos que involucren SharePoint 2010 y en la otra veremos los factores de éxito clave para que una solución de SharePoint sea adoptada por los usuarios finales, evitando los problemas asociados a la gestión del cambio y de adopción entre los usuarios.

Agenda:

  • "ALM en SharePoint 2010. Aumenta la calidad de tus proyectos."
  • "Cómo vender tu solución de SharePoint al usuario final"

Datos de interés:

  • Audiencia: Profesionales de IT.
  • Requisitos previos: Conocimientos de la plataforma SharePoint 2010.
  • Fecha: Jueves 3 de Noviembre de 2011.
  • Hora: 18:00 a 20:00.
  • Formato: Presencial y online, gratuito.

Ponentes:

Edin Kapic, Key Consultant de SharePoint en Pasiona Consulting. Miembro fundador deSUG.CAT y moderador oficial del foro de desarrollo SharePoint de MSDN http://social.msdn.microsoft.com/Forums/es-ES/mossdeves

David Martos González, MVP de SharePoint Server y Arquitecto de software en Spenta Consulting. Miembro fundador deSUG.CAT, escribe habitualmente en su blog http://david-martos.blogspot.com

Podéis inscribiros en esta dirección:

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032496468&Culture=es-ES

Esta vez prometo, si queréis

Si no podéis venir y queréis asistir de manera virtual, podéis utilizar la siguiente dirección:

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032496476&Culture=es-ES

¡Os esperamos a todos!

Actualizado el 27/10/2011

Gracias a mi querido lector B, me he dado cuenta que voy prometiendo cosas a la ligera (leer 5 líneas más arriba). Lo que se quedó en el tintero fue que esta vez, si alguien gusta, se harán unas pertinentes birras al finalizar el evento Smile

¡¡He sido reno-MVP-tizado!!

No hay mejor manera de iniciar la semana (bueno, sí la hay pero en este blog no procede hablar de ellas…) que recibiendo la notificación de que te han renovado como MVP por un año más. Si hace un año informaba con orgullo que había entrado en tan selecto grupo, aún con más orgullo, si cabe, os informo de que me han brindado la posibilidad de seguir estando dentro hasta octubre del año 2012.

A decir verdad no contaba con conseguirlo este año porque los compromisos profesionales me han impedido participar en la comunidad tanto como me hubiera gustado, y la competencia es realmente dura. Espero poder mantener el nivel durante este año aunque ya adelanto que va a ser realmente complicado teniendo en cuenta lo que me trae este año Papa Noel (SPOILER!!!!")

En fin, gracias a todos los que hacen posible que pueda disfrutar de este privilegio, comenzando por mi empresa (Spenta Consulting) que permite que dedique un considerable número de horas a I+D y a organizar eventos y sin olvidarme de mi mujer y de mi gato, que permiten que dedique tantas horas de mi tiempo libre a friquear. Un saludo a todos, y seguimos para bingo…

“A connection will not be made because credentials may not be sent to the remote computer” al instalar Windows 8 en Hyper-V

Hoy, al igual que muchos de vosotros, lo primero que he hecho al empezar el día ha sido instalar mi primer Windows 8 para ver la pinta que tenía. Idealmente lo querría instalar sobre algún dispositivo multitouch en físico pero, a falta de uno, he comenzado por lo más fácil que es instalarlo en una máquina virtual en mi servidor de Hyper-V.

El primer error con el que me he encontrado es el que da título a este artículo: A connection will not be made because credentials may not be sent to the remote computer. La solución al problema ha sido sencilla. Bastará con ir a la consola de administración de Hyper-V, pulsar el botón Hyper-V settings y, en el apartado User Credentials, marcar la opción Use default credentials automatically.

Seguiré informando de cualquier cosa que me encuentre en el proceso de instalación y pruebas.

SharePoint 2010 y .NET Framework 4.0

Hoy un compañero se ha encontrado con algo que no había visto hasta hoy. Como sabréis, SharePoint 2010 funciona con .NET Framework 3.5 (ASP.NET 2.0) y no con .NET Framework 4.0 (ASP.NET 4.0). En una instalación típica de SharePoint esto no será ningún problema pero al parecer en algunas condiciones os encontraréis con que a la hora de crear la aplicación web de la Administración Central durante el periodo de instalación, el sistema intentará crearla con ASP.NET 4.0 y os encontraréis con un error similar al siguiente:

Failed to provision the SharePoint Central Administration Web Application.

An exception of type System.Runtime.InteropServices.COMException was thrown. Additional exception information: Filename: \?C:inetpubwwwrootwssVirtualDirectories46824web.config

Line number: 25

Error: There is a duplicate ‘system.web.extensions/scripting/scriptResourceHandler’ section defined

El fallo es fácil de solucionar. Bastará con ir al IIS y cambiar la versión de .NET Framework establecida para el pool de aplicaciones de la Administración Central de SharePoint. El problema es que haciendo esto no evitaremos que el error vuelva a aparecer cada vez que creamos una nueva aplicación web. ¿Cómo lo solucionamos de manera permanente? Siguiendo los siguientes pasos:

Abrimos la consola de administración de IIS y en el menú de acciones de la derecha pulsamos el enlace Set Application Pool Defaults…

image

En la sección General establecemos el valor de .NET Framework Version como v2.0.

image

Manten limpias tus características

Una de las etapas más aburridas a la vez que necesarias en el desarrollo de software es aquella en la que, una vez lo tenemos todo funcionando perfectamente tenemos que limpiar, pulir y dar cera a los elementos que hemos creado. Algunas tareas que pueden ser relativamente divertidas como refactorizar código y otras que son un absoluto peñazo como, por ejemplo, asegurar que se siguen unas directrices básicas en cuanto a nomenclatura (sí, StyleCop y Resharper nos ayudan bastante pero no impiden que cada developer tiene sus manías a la hora de nombrar clases, por ejemplo).

Hoy, realizando esas tareas de limpieza he dado con un error típico que solemos cometer los que trabajamos con SharePoint debido a cómo Visual Studio 2010 trabaja los conceptos de característica y módulo. El mayor de los problemas es que habitualmente es un error silencioso (y todos sabemos que si algo no hace ruido no es peligroso –salvo la excepción que todos conocemos–) y no solemos prestarles atención.

El problema radica en el hecho que cuando creas un módulo nuevo en Visual Studio 2010, éste se añade a la última característica que hemos añadido a la solución. Si, como es lógico, queremos añadir el módulo a una caacterística concreta, al hacerlo no observaremos ningún mensaje indicando que el módulo ya está añadido a la original. Para evitar este problema basta con mirar la ventana de output de Visual Studio cuando creamos el paquete wsp. Veremos mensajes como los siguientes

c:codeMyProject\PackagePackage.package : warning SPT6: The Project Item "Module1" is included in the following Features: Feature1, Feature2
c:codeMyProjectPackagePackage.package : warning SPT6: The Project Item "Module2" is included in the following Features: Feature3, Feature4

Viendo esto resulta relativamente sencillo ir a aquellas características donde no deberían estar incluídos los módulos indicados en el error y eliminarlos fácilmente.

¿Es buena la complejidad?

Siguiendo una conversación en Twitter de esta mañana, y a riesgo de polemizar un poco más, me tomo la libertad de expresar mi humilde opinión al respecto. No tiene por qué ser una opinión mejor que la del resto, pero tampoco tiene por qué ser peor, es simplemente una opinión más.

Para introduciros en el asunto os resumo un poco la conversación de esta mañana. Aparentemente alguien se quejaba de la complejidad del proceso de instalación de SQL Server y yo apuntaba que en ocasiones los procesos de instalación de aplicaciones debían ser incluso más complejos para evitar problemas futuros causados por instalaciones realizadas por profesional no cualificado para la tarea. La conversación derivó en opiniones relativas a que la instalación de SQL Server en realidad no era tan compleja y, por otro lado, en que justificar la complejidad era fácil, no merecía la pena, y hacía referencia a mentalidades del pasado. A continuación os expongo los motivos que tengo yo para pensar de la manera que pienso.

Primero, decir a los que no me conozcan que soy arquitecto de software especializado en .NET y sobretodo en SharePoint. Mi posición está claramente relacionada con el mundo del desarrollo y mis conocimientos de sistemas no son demasiado avanzados. No obstante, y debido a las particularidades del sector del desarrollo de software en España y debido las particularidades del desarrollo sobre la plataforma SharePoint tengo conocimientos básicos sobre Windows Server (especialmente en todo lo relacionado a los roles de servidor de aplicaciones y a IIS), SQL Server, Exchange Server, TMG, ForeFront, etc. También tengo conocimientos básicos de hardware (sé la diferencia entre RAM y HD, y conozco lo que tiene que tener un equipo para permitir virtualización) pero se me escapan conceptos que seguramente no son altamente avanzados como RAID 0, 1 o 5.

Dicho esto, tengo que decir que en unas pocas horas tengo montado un entorno con varias máquinas virtuales y con todos los componentes mencionados anteriormente instalados y funcionando. Eso significa, en mi opinión, que los procesos de instalación no son excesivamente complejos. Además, si por casualidad tengo que instalar alguna de estas piezas en producción, sé que dispongo de documentación suficiente en Technet (para productos Microsoft) como para hacerlo de manera más o menos adecuada.

Ahora bien, ¿cuál era la razón de mi tweet? Si yo soy capaz de instalar un SQL Server o un SharePoint siguiendo el asistente cualquier persona es capaz de hacerlo. Con cualquier persona no me refiero a “idiotas” (entre comillas que aparentemente no es lo mismo que idiotas) sino a personas que no tienen los conocimientos necesarios para desarrollar la tarea. Pero resulta que estamos en España y aquí, si puedo gastarme menos dinero en hacer una tarea, lo haré. Ahora no entraré en si es el mercado, si es nuestro caracter o si es una mezcla de ambos, pero es un hecho que si se plantea un proyecto de implantación de un producto, el 90% de los casos se lo lleva el que pone un precio hora más barato. Señores, ¿alguien sabe el coste de una persona con los conocimientos necesarios para instalar SharePoint, Exchange, SQL Server o TMG? ¿Alguien conoce una persona que tenga todas esas capacidades con un coste inferior a 20€/h? Que me lo diga que le doblo el sueldo.

Y os preguntaréis qué me importa a mí todo esto. Pues en realidad nada, simplemente expresaba mi opinión. De hecho, mientras las cosas sigan como están seguiré teniendo trabajo arreglando las implantaciones de SharePoint que han sido realizadas siguiendo el asistente. Lo único que me preocupa es que esta práctica siga haciendo daño al nombre de SharePoint, que está lejos de ser una plataforma perfecta (por eso sigo y seguiré teniendo trabajo) pero está aún más lejos de ser la basura que mucha gente piensa que es. Y quien piense que es una basura, que me presente una alternativa y la discutiré con mucho placer.

Y no penséis que estoy planteando proteger mi territorio para que nadie lo pise. Al contrario, fijaos que según lo que comento yo no debería tener “el carné” para instalar SQL Server, por ejemplo. Si pretendemos que traten la ingeniería de software como cualquier otra ingeniería tenemos que plantearnos que tiene que haber especialistas para cada una de las materias. Y ojo, tampoco estoy planteando que para instalar un SQL Server tengas que compilar un kernel. Contra más fácil sea hacer algo mayor será la productividad que es lo que interesa. Lo que yo planteo es que el proceso de instalación podría incorporar alguna característica que impidiera que el sistema funcione adecuadamente hasta que se cumplan ciertos requisitos, de la misma manera que se cambió la política con Windows Server donde por defecto todo está cerrado hasta que alguien va y lo abre.

Ahí queda mi opinión… espero las vuestras para ver si aprendo algo, aunque seguro que ninguno hará cambiar la opinión del otro si no es con cerveza. Con mucha cerveza…

No tengo visor de sucesos – Error 2: The system cannot find the file specified

El otro día un compañero me comentó que no podía conectarse a la VPN y que la máquina le iba, en general, muy mal. Como suele ser habitual en estos casos pasé el marrón a sistemas y me despreocupé por completo, porque para mí VPN son siglas de algo que sé que necesito, pero poco más…

El caso es que hoy me ha tocado sufrir a mí las consecuencias de lo que sea que le pasó a mi compañero y me he quedado sin conexión VPN. El error indicaba que el servicio Remote Access Connection Manager no estaba iniciado. La primera cosa que hice, obviamente, fue intentar iniciarlo. Como no lo conseguí, intenté acceder al visor de sucesos, encontrándome con otro error indicando que el visor de sucesos no estaba disponible. Volví a la consola de servicios y traté de iniciar el servicio Windows Event Log. Fue en ese momento cuando vi el error que encabeza este artículo: Error 2: The system cannot find the file specified.

Después del ataque de pánico inicial y de la pregunta evidente (¿qué fichero?) decidí acudir a mis amigos los foros para dar con lo siguiente:

http://social.msdn.microsoft.com/Forums/en/winserver2008appcompatabilityandcertification/thread/b803a3b0-559f-4a1b-ab44-4bb64e0c746d

Resumiendo, borré la siguiente clave de registro y todo volvió a la normalidad:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetserviceseventlogParameters

Si os preguntáis el por qué, haré como con mi compañero, os redirigiré a sistemas. Lo único que puedo deciros es que de ayer a hoy lo único que cambió en mi entorno fue la instalación de DotTrace y de algunas actualizaciones de Windows.

Autenticación en SharePoint 2010 con sistemas externos mediante Azure ACS v2

Introducción

Aprovechando la aparición del número 8 de la revista CompartiMOSS he pensado publicar la traducción al español de un artículo que recientemente publiqué en el blog de MVP Award Program y que sirve para complementar lo que aparece en la revista ya que, debido a lo extenso que hubiera resultado, no pude detallar como me hubiera gustado.

Antes de explicar cómo conseguir autenticar usuarios de SharePoint 2010 con un sistema externo mediante Azure ACS v2 es conveniente explicar los motivos que nos pueden empujar a querer hacerlo, así que voy a intentar dar mis razones en esta introducción con el lenguaje menos técnico posible.

¿Qué opciones tengo?

Por defecto, SharePoint 2010 permite autenticar a los usuarios mediante Directorio Activo, pero además de esto podemos optar por un repositorio de usuarios diferente mantenido por nosotros mismos como, por ejemplo, una base de datos SQL Server o incluso un sistema totalmente ajeno a nosotros como Windows Live ID, Google o Facebook. En general, la primera opción se aconseja para entornos corporativos por la alta integración que obtendríamos con las herramientas de Office mientras que las otras opciones se suelen recomendar para escenarios públicos. No es una fórmula matemática, pero funciona en la mayoría de casos

¿Por qué utilizar un sistema externo?

Si nos encontramos en una situación donde Directorio Activo no es una opción podemos optar por implementar nuestro propio repositorio de datos o utilizar uno ajeno. Las principales razones que nos empujarían a la segunda opción son:

  • No tenemos que preocuparnos por mantener la información en nuestro propio sistema ni de asegurar su integridad.
  • No es necesario implementar mecanismos relacionados con la gestión de usuarios como, por ejemplo, registro de usuario o recuperación de contraseña.
  • Nuestros usuarios no tendrán que mantener otro conjunto de credenciales adicional a los que ya tenían.

Si tenemos claro que queremos utilizar un sistema externo la siguiente pregunta a realizarnos sería si necesitamos utilizar un único sistema o queremos federar las identidades de varios de ellos. Si nos encontramos en el segundo caso aparecen dos alternativas posibles: ADFS 2.0 o Azure ACS v2, que podría ser traducido como ADFS 2.0 en la nube.

¿Por qué utilizar Azure ACS v2 en lugar de ADFS 2.0?

Siempre que comparamos una plataforma instalada on-premises con la misma plataforma utilizada como servicio aparecen los mismos argumentos:

  • Escalabilidad
  • Mantenibilidad
  • Coste (TCO)
  • Rendimiento
  • Etc.

Cada una de las dos alternativas tendrá unas valoraciones diferentes para cada argumento. Si ponemos en una balanza todos estos argumentos con el peso que demos a cada uno de ellos tendremos la respuesta a la pregunta planteada anteriormente.

Manos a la obra

Si después de plantearte todas las preguntas anteriores has llegado a la conclusión de que quieres utilizar varios sistemas externos y quieres utilizar los servicios de autenticación que proporciona Azure, te interesa seguir leyendo para saber cómo configurar SharePoint 2010 para poner todo esto en marcha.

Antes de comenzar a configurar nada conviene plantearnos lo que queremos implementar. Para el ejemplo que nos ocupa yo he pensado crear un portal público en la url https://www.contoso-acsv2.com con acceso anónimo permitido y con un área privada a la que únicamente se puede acceder con unas credenciales válidas de Windows Live ID o de Google. Con esta información podemos comenzar a preparar nuestra granja de SharePoint 2010 para dar soporte a este escenario.

Doy por sentado que aquellos que estáis leyendo este artículo tenéis los conocimientos necesarios para realizar las tareas de alto nivel que voy a especificar a continuación pero, si no es así, no dudéis en enviarme vuestras preguntas o comentarios. En cualquier caso, ya os adelanto que al final de este artículo os dejaré un enlace donde podréis acceder a un entorno totalmente preparado y que podréis utilizar a vuestra conveniencia.

1. Creación de una aplicación web para acceso interno con la siguientes características

  • Autenticación basada en claims (IMPORTANTE!)
  • SSL no habilitado
  • Autenticación NTLM
  • Acceso anónimo no habilitado

2. Creación de una colección de sitios a partir de la plantilla de sitio de publicación. Antes de continuar con el artículo comprobar que podemos navegar a la colección de sitios que acabamos de crear. Observaréis, en la parte superior de derecha, que el usuario con el que os habéis conectado es un usuario de Directorio Activo.

Antes de proceder con la siguiente tarea necesitaremos crear un certificado digital para firmar los tokens. Aprovechando el hecho que también necesitaremos un certificado para el sitio que publicaremos por https y teniendo en cuenta que lo que vamos a hacer es únicamente para pruebas, procederemos de la siguiente manera:

1. En el servidor de SharePoint, abrir una ventana de comandos y situarse en la carpeta C:Program FilesMicrosoft Office Servers14.0Tools.

2. Ejecutar el siguiente comando: MakeCert.exe -r -pe -n "CN=www.contoso-acsv2.com" -sky exchange -ss my

3. Abrir con la consola de administración ejecutando el comando mmc.exe y añadir el snap-in de certificados del usuario actual.

4. Localizar en la carpeta personal el certificado para www.contoso-acsv2.com y exportarlo al disco duro. Aprovechad este momento para exportarlo con (.PFX), y sin clave privada asociada (.CER) ya que necesitaremos ambos en diferentes partes de este artículo.

Nota: en un escenario real deberíais utilizar certificados diferentes para firmar tokens y para el servidor web. Además, no se recomienda utilizar certificados auto-generados para entornos en producción.

Una vez creada la colección de sitios con la que trabajaremos y generado el certificado digital, lo siguiente que tendremos que hacer es crear un espacio de nombres en Azure ACS v2 que identifique nuestra aplicación y, para ello, deberemos seguir los siguientes pasos:

1. Acceder al portal de AppFabricLabs (https://portal.appfabriclabs.com)

Nota: este artículo utilizará la versión de laboratorio de Azure ACS v2, que es gratuíta pero que no puede utilizarse en entornos reales en producción. La versión comercial de Azure ACS v2 está disponible a través del portal de Windows Azure.

2. Localizar y pulsar, en la parte inferior izquierda de la pantalla, el enlace Service Bus, Access Control & Caching.

3. Seleccionar Access Control en el menú de navegación de la izquierda y pulsar el botón New Namespace en la ribbon.

4. Rellenar el formulario indicando un espacio de nombres que esté disponible y una región (de momento únicamente podemos seleccionar Estados Unidos)

5. Pulsar el botón Create Namespace y esperar a que el servicio pase a estado activado.

Una vez creado y activado el espacio de nombres, la siguiente tarea consiste en configurarlo para que de soporte a nuestras necesidades. Para ello procederemos de la siguiente manera:

1. Seleccionar el espacio de nombres y pulsar el botón Access Control Service en la ribbon. Esto nos llevará al portal de administración de nuestro espacio de nombres.

2. Pulsar el enlace Identity providers en el menú de navegación de la izquierda. Veréis que, por defecto, el sistema nos va a permitir utilizar Windows Live ID como sistema de autenticación.

3. En este artículo queremos demostrar el uso de más de un sistema de autenticación y, por lo tanto, pulsaremos el enlace Add y añadiremos Google a la lista de proveedores autorizados. Vosotros, si lo preferís, podéis añadir Facebook o Yahoo.

4. La siguiente pantalla os permitirá indicar un texto y una imagen que se utilizará en la pantalla de inicio de sesión a la hora de seleccionar el proveedor que queremos utilizar para ingresar en el sistema. Podéis dejar los valores por defecto y pulsar el botón Save.

5. Pulsar el enlace Relying Party Applications en el menú de navegación de la izquierda y pulsar el botón Add que aparece en la siguiente pantalla.

6. Rellenar el formulario con los siguientes valores y pulsar el botón save.

  • Name: contoso-acsv2.com
  • Realm: https://www.contoso-acsv2.com/
  • Return URL: https://www.contoso-acsv2.com/_trust/
  • Token format: SAML 1.1
  • Token lifetime: 600 secs
  • Google: opción marcada
  • Live ID: opción marcada
  • Create new rule group: opción marcada
  • Token signing: Use a dedicated certificate (poner aquí los valores que habéis obtenido a la hora de exportar el certificado digital con clave privada)

7. Pulsar el enlace Rule groups en el menú de navegación de la izquierda y, en la lista que aparece, pulsar el enlace Default rule for contoso-acsv2.com. Una vez allí, pulsar el enlace Generate, dejar marcadas las opciones Windows Live ID y Google y pulsar el botón Generate.

8. La siguiente pantalla nos mostrará los claims que vamos a recibir de aquellos sistemas con los que nos integremos. En nuestro caso vamos a hacer un pequeño cambio. Debido a que Live ID no nos envía el email del usuario y nosotros queremos utilizar este claim más adelante añadimos un nuevo claim con los siguientes valores:

  • Identity Provider: Windows Live ID
  • Input Claim Type: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
  • Output Claim type: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Teniendo configurado nuestro espacio de nombres en Azure ACS v2 y con el certificado preparado podemos proceder a configurar nuestro proveedor autorizado de autenticación en SharePoint 2010. Para ello seguiremos los siguientes pasos:

1. Copiar el texto a continuación y guardarlo como fichero con extensión ps1 en la carpeta donde anteriormente exportamos el certificado digital.

$realm = "https://www.contoso-acsv2.com"

 

$signinurl = "https://example-acsv2.accesscontrol.appfabriclabs.com/v2/wsfederation" 

 

$certloc = (Get-ChildItem . -Recurse -include www.contoso-acsv2.com.cer).fullname

 

$rootcert = Get-PfxCertificate $certloc

 

New-SPTrustedRootAuthority "Azure ACSv2" -Certificate $rootcert 

 

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc)

 

$map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "Email" -SameAsIncoming 

 

New-SPTrustedIdentityTokenIssuer -Name "Azure ACSv2" -Description "Windows Azure ACS v2" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType

 

2. Abrir la Consola de Administración de SharePoint 2010 y ejecutar el fichero previamente guardado.

Ya estamos en disposición de continuar nuestro trabajo en la Administración Central de SharePoint. Nos faltaría únicamente extender la aplicación web que creamos al inicio de este artículo usando, para ello, las siguientes configuraciones.

  • Puerto: 443
  • Host header: www.contoso-acsv2.com
  • Acceso anónimo: habilitado
  • SSL: habilitado
  • Proveedor de autenticación: Azure ACSv2

Antes de poder acceder al sitio web que acabamos de crear necesitaremos realizar algunas tareas relacionadas con certificados.

1. Abrir la consola de Internet Information Services, seleccionar el nombre de nuestro servidor en la sección de la izquierda y abrir la característica Server Certificates en la ventana principal.

2. Importar el certificado con clave privada (.PFX) mediante el menú de acciones de la derecha.

3. Pulsar con el botón derecho del ratón sobre el sitio web que hemos creado para acceder mediante SSL y seleccionar Edit Bindings.

4. Editar el enlace que se ha creado por defecto y asignarle el certificado que previamente hemos importado.

Una vez hecho esto ya podréis navegar a la url https://www.contoso-acsv2.com y, como veréis, el sistema os redigirá a una pantalla donde os aparecerá la lista de proveedores de identidad que habéis configurado en Azure ACS v2 (en nuestro ejemplo Windows Live ID y Google). Pero si intentáis acceder con vuestras credenciales recibiréis un error. Aún es necesario un último paso que consiste en acceder de nuevo a la gestión de certificados del servidor de SharePoint y copiar el certificado generado para www.contoso-acsv2.com que encontraremos en la carpeta Personal a las siguientes tres carpetas:

  • SharePoint
  • Trusted People
  • Trusted Root Certification Authorities

En estos momentos ya podéis acceder al sitio pero, obviamente, recibiréis un error de acceso denegado. A modo de demostración daremos acceso de lectura total a cualquier usuario que se identifique con unas credenciales válidas. Para ello seguimos los siguientes pasos:

1. Desde la administración de aplicaciones web en la Administración Central de SharePoint seleccionamos la aplicación web que creamos al inicio de este artículo.

2. Pulsamos en la ribbon el botón User Policy.

3. Seleccionamos ‘All Users [Azure ACSv2]’ y le asignamos permisos de lectura total.

De cara a obtener el entorno dal cual lo habíamos planteado al inicio será necesario habilitar el acceso anónimo en la colección de sitios y crear un subsitio con permisos específicos en el cual no esté habilitado el acceso anónimo. Al volver a ser una tarea de alto nivel que no tiene ninguna relación con Azure ACS v2 no detallaré los pasos pero, de nuevo, si tenéis algún tipo de duda en este punto no dudéis en dejarme un comentario.

Finalmente ya tenemos nuestro entorno totalmente preparado. A partir de este momento, cada vez que accedamos a la url https://www.contoso-acsv2.com el sistema nos permitirá indicar unas credenciales válidas en Windows Live ID o en Google para acceder al sistema. Evidentemente esto es únicamente el punto de partida para comenzar a trabajar con Windows Azure ACS v2 ya que se abre un amplio abanico de posibilidades. Si queréis comenzar a explorar este mundo y no queréis perder tiempo preparando este entorno, he publicado un permalink con todo lo que he explicado en este artículo totalmente configurado y que podéis utilizar a vuestra conveniencia.

Disponible el nº 8 de la revista CompartiMOSS

Acaba de publicarse el número de Junio de la revista CompartiMOSS, gestionada por los grandes Fabián Imaz, Gustavo Vélez y Juan Carlos González. Por segunda vez consecutiva he tenido el placer de colaborar con un artículo relativo a autenticación. También se incluye un artículo sobre Beezy, sobre el cual he hablado en otras ocasiones y seguiré hablando siempre que me sea posible. El índice general de la revista es el siguiente:

  • Editorial
  • Autenticación en SharePoint 2010 – II (David Martos)
  • El lado social de SharePoint – II (Alberto Díaz Martín)
  • Buenas prácticas en la implementación de Project Server 2010 (Juan Pablo Pussacq Laborde)
  • Entrevista con Juan Carlos González
  • Tips para la personalización de My Sites en SharePoint 2010 (Carlos Ariel Dantiags)
  • QualitasLearning – Sistema de formación virtual en SharePoint Server 2010 (Alberto Aunchayna)
  • Workaround para permitir filtrados por metadatos múltiples en el Content Query WebPart (Luis Máñez, Teresa Cebrián)
  • Herramienta para configurar listas y bibliotecas de documentos de forma masiva (Fabián Imaz)
  • TRAMAT-SharePoint
  • Como configurar la integración entre Microsoft Dynamics CRM 2011 y SharePoint 2010? (Pablo Peralta)
  • Beezy, redes #sociales corporativas sobre SharePoint

Podéis descargar la revista aquí.

SharePoint 2010 y Visual Studio 2010 o si es oro todo lo que reluce…

Leyendo el título de este artículo alguno podría imaginar que voy a hablar mal de SharePoint o de Visual Studio pero, si me conocéis, sabéis que esto no sería demasiado normal. Aunque nunca diré que son productos perfectos que colman todas mis necesidades en cualquier momento, muchos de los problemas que les encuentro acaban teniendo una razón más humana de lo que parece inicialmente.

Hasta la llegada de Visual Studio 2010, aquellos que desarrollábamos proyectos basados en SharePoint teníamos bastante más trabajo y, a su vez, bastante más control. Sí, realizar un buen trabajo era más complicado pero cuando tu solución no se creaba o no se desplegaba solías tener más control sobre qué estaba pasando. Con la nueva versión de Visual Studio se había automatizado tanto el proceso que, en ocasiones, daba la sensación de que los desarrolladores habíamos perdido el control y en ocasiones pensabas qué pasaría con aquellos que comenzaban a desarrollar directamente para SharePoint 2010, ¿sabrían por qué pasaban las cosas y qué había detrás de cada elemento de la solución?

Hoy me he encontrado en uno de esos momentos en los que piensas que en realidad todo ha sido un paso atrás. La costumbre de que pulsando con el botón derecho del ratón sobre tu proyecto y seleccionando la opción Desplegar todo se llevase al sitio que tocaba de manera automática ha hecho que me relaje y he estado todo el día dándole vueltas a un error que aparecía sin razón alguna y, como no, he acabado culpando a SharePoint y a Visual Studio.

Al final he hecho lo que es más aconsejable en estos casos: irme a casa, relajarme, ver una peli y, con la mente limpia… volver a revisar el problema. Y ha sido entonces cuando he empezado a ver algo de luz. Cuando generaba la solución de SharePoint 2010 no aparecía ningún error en el proceso. Visual Studio no me sacaba ningún mensaje advirtiendome de que algo no iba bien. ¿O sí lo hacía…? Pues efectivamente, lo hacía. Una rápida mirada a la salida de la generación me ofrecía la siguiente visión:

 

Spenta.Beezy.WebParts -> c:codeSpenta.BeezySpenta.Beezy.WebPartsbinDebugSpenta.Beezy.WebParts.dll
—— Build started: Project: Spenta.Beezy.Receivers, Configuration: Debug Any CPU ——
Spenta.Beezy.Receivers -> c:codeSpenta.BeezySpenta.Beezy.ReceiversbinDebugSpenta.Beezy.Receivers.dll
Error: Object reference not set to an instance of an object.
========== Build: 10 succeeded or up-to-date, 1 failed, 0 skipped ==========

 

Hubiera agradecido que la parte que yo he resaltado hubiera sido más evidente en la ventana de Visual Studio pero en cualquier caso hay que decir que el error era bastante claro y era el primer sitio que tenía que haber mirado después de 20 veces buscando una razón para algo inexplicable. También tendría que haberme hecho recapacitar el hecho que la fecha de última modificación del paquete generado era de hacía unas horas. En cualquier caso, viendo la raíz del problema lo siguiente era investigar la causas y, claro está, resolverlas. Y aquí volveríamos al asunto sobre el cual gira este artículo: antes hubiera ido a la ventana de MS-DOS y hubiera ejecutado unos cuantos comandos para resolver el entuerto pero… ¿Qué hago ahora que todo está tan automatizado y tan integrado?

Me disponía ya a abrir la consola de comandos para hacerlo todo a la antigua usanza cuando el poco de sentido común que me queda me hizo pensar que era imposible que Microsoft no hubiera pensado en estas situaciones, y fue entonces cuando vi algo que hasta la fecha no había visto (en parte por no haberlo necesitado, en parte por mirar siempre la pantalla en diagonal).

Cuando tenéis ese error en la ventana de salida de compilación, veréis que podéis elegir que se muestre información sobre las SharePoint Tools en el desplegable al inicio de la ventana. En mi caso, al seleccionar esa opción vi lo siguiente:

 

{ProjectRoot}pkgDebugSpenta.BeezySpenta.Beezy.WebParts.dll -> GAC
EXCEPTION: Access to the path ‘c:codeSpenta.BeezySpenta.BeezypkgDebugSpenta.BeezyMicrosoft.Practices.Unity.dll’ is denied.
{ProjectRoot}pkgDebugSpenta.BeezyMicrosoft.Practices.Unity.dll -> GAC
========== Copying to GAC/BIN succeeded ==========

 

Como podéis ver, el error era bastante evidente y era simplemente un ensamblado que no acababa de copiarse porque algún proceso lo tenía atrapado. Claro, una vez visto el problema real, la solución apareció en cuestión de segundos y todo empezó a funcionar a las mil maravillas. Moraleja: KISS (Keep It Simple Stupid), si algo que tiene que ir, no va, antes de buscarle los tres pies al gato busca las cosas más simpels.