SharePoint 2013 - SQL Server instance does not have the required "max degree of parallelism"

No sé ustedes pero yo personalmente aún ahora, probando el preview de SharePoint 2013, cruzo los dedos cada vez que el wizard de configuración se encuentra en el paso "Creating the configuration database…"

Precisamente el error del que hablaremos el día de hoy, ocurre al momento de estar creando la base de datos de configuración de nuestra flamante granja de SharePoint 2013:

Failed to create the configuration database.

This SQL Server instance does not have the required "max degree of parallelism" setting of 1. Database provisioning operations will continue to fail if "max degree of parallelism" is not set 1 or the current account does not have permissions to change the setting. See documentation for details on manually changing the setting.

Lo único rescatable de este escenario de error es que si te llega a ocurrir, es porque casi seguramente estas usando la filosofía de mínimos privilegios o least-privileges, es decir la cuenta con la que estas instalando SharePoint 2013 solo tiene los roles dbcreator y securityadmin de base de datos, lo cual es muy bueno pero insuficiente para modificar el setting “max degree of parallelism” por el cual ocurre el error. De hecho si lees bien el mensaje de error, si la cuenta que será usada como Farm Administrator tuviera permisos de modificar el setting, lo hubiera hecho.

Ahora bien, después de la sección de reflexiones, como se resuelve este inconveniente?

Primero le llamas al amigo DBA, o consigues una cuenta administradora de la base de datos. Para modificar el “max degree of parallelism” puedes ocupar cualquiera de las siguientes dos opciones:

Utilizando la UI
1. Abrir Microsoft SQL Server Management Studio
2. Conectarse a la instancia en la que se intenta crear la granja de SharePoint, con la cuenta administradora
3. Hacer click en Properties sobre el nombre de la instancia, aparecerá un cuadro de dialogo
4. Modificar a 1 el valor del elemento Max Degree of Parallelism

Utilizando el stored procedure sp_configure
Ejecuta las siguientes instrucciones en una ventana de query

sp_configure 'show advanced options', 1; 
GO
RECONFIGURE WITH OVERRIDE; 
GO
sp_configure 'max degree of parallelism', 1; 
GO
RECONFIGURE WITH OVERRIDE; 
GO

Después de ejecutar cualquiera de estas dos soluciones no olvides borrar la base de datos SharePoint_Config, que se creó en el intento fallido de creación de la granja. Por último vuelve a ejecutar el wizard para la configuración de la granja de SharePoint 2013

Y bueno, mientras ven como avanza el wizard, no estaría demás que leyeran las siguientes referencias:

Install and Configure SharePoint 2013 preview
Deployment guide for Microsoft SharePoint 2013 preview
General guidelines to use to configure the MAXDOP option
The ins and outs of MAXDOP

Happy Configuring!

[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!

QI for IEnumVARIANT failed on the unmanaged server

Bueno, por si alguna vez les ha ocurrido este error al tratar de ingresar a la página de administración del servicio de búsqueda.

Inclusive al intentar recuperar algún valor mediante PowerShell este mismo error aparece, una posible solución que a mí me funciono fue reiniciar el IIS utilizando el siguiente comando

iisreset /noforce

Esto en cada uno de los servidores de crawling

Happy Configuring!