[Webcast] - Habilitar el uso de Silverlight en SharePoint

Hola, el día de hoy quiero compartir con la comunidad, un pequeño video que grabe en dias pasados en el que describo de manera breve, los pasos necesarios para configurar el uso de Silverlight en la plataforma SharePoint.

Cabe mencionar que si alguien, tiene alguna duda o sugerencia para nuevos temas de Webcast dejen sus comentarios, ya que mediante estos me estaré basando para futuras entregas.

SharePoint Designer no permite el acceso a ningún sitio

Hace poco me disponía alegremente a utilizar SharePoint Designer 2007, cuando al intentar abrir cualquier sitio me desplegaba un mensaje de error indicándome que no contaba con los permisos suficientes, y me sugería pedir más permisos al administrador del sitio web.

En primer instancia me preocupe por algún posible problema de bipolaridad ó personalidades múltiples, ya que yo soy el administrador de la granja!!!.

Pero después de analizarlo con un cappuccino, me hice a la idea de que esto tenía que deberse a alguna ultima modificación ó configuración hecha sobre la granja en los últimos dias. Afortunadamente el proceso de eliminación fue fácil, un dia antes había descargado e instalado la feature 3.5 Web.Config, que se encuentra disponible dentro de todo un conjunto de features para SharePoint 2007 disponibles en codeplex.

Analizando un poco las modificaciones hechas en el web.config, a partir de la instalación de esta feature, me dí cuenta de algo ilógico.

<httphandlers>
 <remove path="*" verb="GET,HEAD,POST"/>
 <add path="*" type="Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" verb="GET,HEAD,POST">
 <add path="*" type="Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" verb="OPTIONS,PROPFIND,PUT,LOCK,UNLOCK,MOVE,COPY,GETLIB,PROPPATCH,MKCOL,DELETE,(GETSOURCE),(HEADSOURCE),(POSTSOURCE)">
 <add path="Reserved.ReportViewerWebControl.axd" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" verb="*">
 <add path="*.asmx" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" validate="false" verb="*">
 <add path="*_AppService.axd" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" validate="false" verb="*">
 <add path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" validate="false" verb="GET,HEAD">
 <remove path="*.asmx" verb="*"/> 
</httphandlers>

Y es que como se puede observar, al final de la declaración  de los httphandlers, se agrega una declaración removiendo a todos los manejadores para archivos .asmx, go tha hell asmx files!. Como todos sabemos, SharePoint Designer hacen uso extensivo de los web services expuestos por SharePoint, pero como sus manejadores son removidos por la feature, al momento de solicitar el acceso para un usuario a través del servicio /_vti_bin/usergroup.asmx, este devuelve un error 401.

La solución rápida es muy simple, modificar el archivo web.config y colocar la línea siguiente al principio del bloque de httphandlers

<remove path="*.asmx" verb="*"/> 

Asi:

<httphandlers>
 <remove path="*" verb="GET,HEAD,POST"/>
 <remove path="*.asmx" verb="*"/> 
 <add path="*" type="Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" verb="GET,HEAD,POST">
 <add path="*" type="Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" verb="OPTIONS,PROPFIND,PUT,LOCK,UNLOCK,MOVE,COPY,GETLIB,PROPPATCH,MKCOL,DELETE,(GETSOURCE),(HEADSOURCE),(POSTSOURCE)">
 <add path="Reserved.ReportViewerWebControl.axd" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" verb="*">
 <add path="*.asmx" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" validate="false" verb="*">
 <add path="*_AppService.axd" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" validate="false" verb="*">
 <add path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" validate="false" verb="GET,HEAD">
</httphandlers>

La mejor solución es modificar el código de la feature, para que en usos posteriores ya no se presente este error. Para solucionar este error solo tienen que seguir estas instrucciones, para modificar la clase \Features_Project\3.5.Config\FeatureReceiver_35_SL.cs

//**********************************
// Modified Here in order to fix a bug where the "remove" tag was being added to the end of the section.
// From: "configuration/system.web/httpHandlers",
// To: "/configuration/system.web/httpHandlers",

// It turns out that the MS implementation of the webconfig modification class puts mods into an alphabetically sorted list (one for each type)
// and ignores the Sequence number.
// (Actually it's not ignored but seems to be used to determine a winner in case of a modification naming collision.)
// The sorting is done on the full string of (path + "/" + name)
// What this means for us is that as long as the "/" character sorts in front of the "a" character then this hack will cause the implementation to 
// add our modification after before the following "add" modifications.
AddNodeValue(
"remove[@path='*.asmx']",
"/configuration/system.web/httpHandlers",
@"<remove *.asmx="" *="" path="" verb=""> "</remove>
);
//***********************************

Happy Coding!

La búsqueda de personas no funciona en SharePoint

Si alguna vez les ha pasado que en sus sitios de sharepoint las búsquedas de personas no funcionan. Es decir las búsquedas de contenido en el sitio funcionan correctamente pero no así la de personas, esto es muy fácil de solucionar.

Solo vayan al sitio central de administración -> sitio de administración del SSP -> Search Settings -> Content Sources and Crawl Schedules. Editen el source que contiene el sitio que no devuelve resultados en las búsquedas de personas y agreguen otra entrada con la url de su sitio sustituyendo el protocolo por sps3.
Asi:
http://mysite:8080
sps3://mysite:8080

Además les dejo un pequeño screencast en el que se aprecia mejor esto.

Authentication failed because the remote party has closed the transport stream

Hace poco en una implementación más, de mi producto favorito: vodka con jugo de piña MOSS 2007, me tope con un error al momento de intentar acceder a la página de configuración de búsquedas que se encuentra dentro de la web application Admin del SSP (Shared Services Provider) http://myserver:11300/ssp/admin/_layouts/searchsettings.aspx.

El error decía algo más o menos así:

Could not connect to server “SERVER_NAME” for application 'SSP'. This error might occur if the server is not responding to client requests, the firewall or proxy configuration is preventing the server from being contacted, or the search administration Web service is not running on the server.

Inmediatamente después intente accede a la página de administración de búsquedas: http://myserver:11300/ssp/admin/searchadministration.aspx., para ver si por ahí podía arreglar este problema, pero aquí surgió otro mensaje de error OMFG!:

Authentication failed because the remote party has closed the transport stream.

Al revisar los logs de SharePoint, me di cuenta que el servidor1 no se podía comunicar con el webservice del servicio de búsqueda del servidor2. Ya que este le denegaba el acceso a la url:

https://server2:56738/SharedServicesProvider1/Search/SearchAdmin.asmx.

Después de maldecir buscar un rato en la red, me encontré que este es un issue conocido por Microsoft y es documentado por el kb “You cannot browse to an SSL-secured Office SharePoint Server 2007 site or to the Search Settings page for a Shared Services Provider”.

Y es provocado por el .Net Framework 3.5 SP 1, que hace que los certificados auto firmados (“self signed”), sean corruptos o no sean de confianza. Sin embargo la solución es sencilla, a continuación los pasos de manera resumida de los que se debe hacer en cada uno de los servidores.

1.- Descargar el Internet Information Services (IIS) 6.0 Resource Kit Tools e instalarlo.

2.- Parar el servicio de busqueda con el commando net stop osearch.

3.- En cada uno de los servidores de la granja de SharePoint ejecutar el comando selfssl /s:951338967 /v:1000, utilizando la utilería selfssl que acabamos de instalar. El directorio de default de instalación es: “c :\Program Files\IIS Resources\SelfSSL”

Parametros:

/s: 951338967. El valor 951338967, se refiere al Id de los servicios web de Office Server, para servidores de 64 bits. Si tu servidor es de 32 bits, el id que debes usar es el 1720207907

/v:1000. Número de días por los que el certificado será válido, Aquí puedes usar un numero mas grande, si así lo deseas.

4.- Por último, pero no menos imprtante, reiniciar el servicio de busqueda, con el comando net start osearch

Recursos:

kb 962928

Internet Information Services (IIS) 6.0 Resource Kit Tools

Recursos de mi participación en la 2da semana Académica en el TESSFP

Como había prometido, dejo la presentación que realice en pasados días en el TESSFP. Gracias por la invitación a participar en este evento académico, en donde hubo grandes expositores y grandes platicas para los alumnos.

Fue una experiencia enriquecedora.

Espero verlos pronto de nuevo.

La presentación.

Más fotos