Sexto Simposio LatinoAmericano de SharePoint

Como cada año se llevó a cabo el sexto simposio latinoamericano de SharePoint, en el cual tuve el privilegio de participar en la presentación "El poder del Business Intelligence con Visio 2010 y SharePoint 2010" en conjunto con Elizabeth Contreras (Project Manager de Project y Visio en Microsoft México) y Antonio Razo (Consultor Sr de BI), a continuación les comparto la ppt que presente.

Cualquier comentario es bienvenido

Happy Coding!

Sexto Simposio Latinoamericano de SharePoint en México

Como ya se está volviendo tradición, este año se llevara a cabo de nueva cuenta el Simposio Latinoamericano de SharePoint en México, siendo este el primer año en que se estará transmitiendo a través de Live Meeting.

El evento presencial será de nueva cuenta en las oficinas de Microsoft México

Aquí la invitación oficial:

No olviden realizar su registro y allá nos vemos :)

[SharePoint Troubleshooting] - Access Denied PRTH_E_ACCESS_DENIED en servcio de búsqueda

En los pasados días me encontré con el siguiente escenario en la granja de SharePoint 2010 de uno de mis clientes. Se tiene el servicio de búsqueda creado y configurado adecuadamente, de hecho ya tiene unos meses funcionando con normalidad y la búsqueda funciona en todos los sitios de la compañía. De pronto un día notan que en un Web Application en particular la búsqueda no está mostrando resultados.

De manera sistemática, algunas de los primeros puntos a revisar en este escenario fueron:

• Privilegios de la cuenta de acceso al contenido
• Que el host header del web application que no devuelve resultados este agregado dentro de las direcciones a rastrear dentro de alguno de los orígenes de contenido
• Que el servicio de búsqueda esté funcionando y/o verificar cuando fue la última vez que se realizo un rastreo

Después de revisar los puntos anteriores, nos damos cuenta que todo parece ir bien con el servicio de búsqueda, solo vemos un par de errores en el log de rastreo de uno de los orígenes de contenido, y que precisamente corresponde al sitio en que no se muestran resultados de las búsquedas, pero no hay mayor información de cuál es el origen de estos errores.

Después de mucho buscar en los logs de SharePoint, encontramos los siguientes mensajes.

CHttpAccessorHelper::InitRequestInternal - Access Denied PRTH_E_ACCESS_DENIED on request for "http://extranet.xxxxx.xxx" hr = 0x80041205 [httpacchelper.cxx:268] d:\office\source\search\native\gather\protocols\http\httpacchelper.cxx

CHttpProbeHelper::ProbeServer:InitiRequest failed for "http://extranet.xxxxxx.xxx" Return error to caller, hr=80041205 [stscommon.cxx:439] d:\office\source\search\native\gather\protocols\common\stscommon.cxx

Lo que nos da una pequeña pista, se trata de permisos de la cuenta de acceso. Intentamos acceder al sitio utilizando esta cuenta desde el servidor que tiene el servicio de búsqueda,  después de ingresar las credenciales, nos aparece la pantalla de login de manera repetida (tres veces) hasta que nos presenta un error de autentificación. Estonces llegamos a la raíz del error, no es un problema de permisos de la cuenta sino un tema de configuración, ya que es un comportamiento que he visto bastante y que se refiere a la configuración de la característica de seguridad DisableLoopbackCheck, de la cual ya he hablado anteriormente.

Todo se soluciona, siguiendo el KB 896861 y aplicando las configuraciones que correspondan en los servidores SharePoint, Si no sabes si deshabilitar la caracteristica DisableLoopbackCheck o agregar una entrada en BackConnectionHostNames, te recomiendo leer mi post en donde hablo de cuando aplicar una u otra solución

Happy configuring!

Warning - SPTraceV4 utiliza una cuenta integrada para su ejecución

Siempre es importante revisar las alertas que emite en servicio de SharePoint Health Analyzer, sobre todo cuando tienen el nivel de severidad 1 – Error, además de que no hay pretextos ya que es bastante llamativa la forma en que SharePoint nos avisa que debemos revisar algún issue detectado por la ejecución de este servicio.

Bueno, pues en un día normal de un SharePoint Farm Administrator me encontre con el siguiente warning, es decir tenía el nivel de advertencia y no de error, aún así se deben tomar medidas para revisarlo y resolverlo.

Para la mayoría de los servicios de SharePoint puedes solo navegar a la página de Administración de cuentas de servicio de la granja para modificar la cuenta con la cual se ejecuta, sin embargo no es posible hacerlo para este servicio debido a que no aparece listado ahí. Luego entonces lo más lógico y sencillo es hacerlo desde la Consola de Administración de Servicios de Windows, desde donde podemos ver que efectivamente el servicio está utilizando una cuenta integrada (en este caso Local Service) para su ejecución, lo recomendado es que sea una cuenta de dominio.

Lo primero que se podría pensar es en cambiarlo directamente ahí… desafortunadamente esto no soluciona el problema, en primera instancia porque habría que hacerlo para todos los servidores de la granja. Y una vez que hayamos aplicado este cambio en todos los servidores de la granja intentaríamos ejecutar de nuevo el análisis de la regla, solo para darnos cuenta que no sirve de nada.
 

La explicación es que el servicio de Health Analyzer checa el valor en la base de datos de configuración de SharePoint y no directamente del valor del servicio. Entonces lo que se debe hacer es ejecutar el siguiente script, como se indica en este thread del foro de SharePoint de Microsoft.

# Get the tracing service.
$farm = Get-SPFarm
$tracingService = $farm.Services | where {$_.Name -eq "SPTraceV4"}  
 
# Get the "farm" managed account.
$managedAccount = Get-SPManagedAccount "DOMAIN\spfarm"
 
# Set the tracing service to run under the managed account.
$tracingService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$tracingService.ProcessIdentity.ManagedAccount = $managedAccount
$tracingService.ProcessIdentity.Update()
 
# This actually changes the "Run As" account of the Windows service.
$tracingService.ProcessIdentity.Deploy()

Por último recordarles que la cuenta de dominio que utilicen para el servicio SPTraceV4 debe reunir los siguientes requisitos:

1. Tener permisos de lectura y escritura sobre la carpeta en que se guardaran los logs, que por default es C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS
2. La cuenta debe estar dentro de los grupos locales Performance Monitor Useres y Performance Log Users

Happy Configuring!

MVP SharePoint Server 2012

Pues nada, que he recibido ÉL famoso e-mail:

“Estimado Gerardo Reyes,

Enhorabuena. Nos complace presentarle el programa de nombramiento MVP de Microsoft® de 2012. Este nombramiento se concede a los líderes excepcionales de la comunidad técnica que comparten de forma activa su experiencia de alta calidad y de la vida real con otras personas. Le agradecemos especialmente la contribución que ha realizado en las comunidades técnicas en el área de SharePoint Server a lo largo del pasado año.”

Que me acredita como MVP en SharePoint Server para este 2012, y que sin duda me motiva para seguir capacitándome y compartiendo mis experiencias del día a día con las comunidades técnicas.

Gracias a toda la gente que ha influido de una u otra forma en mi crecimiento como consultor y como persona. Especiales agradecimientos y #FF a:

@SrBichi
@mmonterroca
@haarongonzalez
@HardBit
@Virtualman
@jluisestrada
@jrwarrior
@ferglo

Happy Coding!