SharePoint 2010 – The search service is not able to connect to the machine that hosts the administration component

Tengo una granja configurada de dos servidores de SharePoint 2010, uno de ellos (servidor1) mantiene el sitio de Administración Central mientras que el otro (servidor2) los servicios de búsqueda e indexación. Por medio del sitio de Administración Central traté de configurar una “Search Service Application” sin embargo al ingresar en la página de administración de contenido y reglas se presentó el mensaje “The search service is not able to connect to the machine that hosts the administration component…”.

Al revisar y comprobar por medio de la consola de PowerShell el estado del servicio apareció que el nombre del servidor estaba asignado a aquel que no tenía los servicios de búsqueda activos, es decir el servidor1.

Para resolver esto tuve que seguir los pasos indicados en este sitio http://blogs.msdn.com/b/russmax/archive/2009/10/20/sharepoint-2010-configuring-search-service-application-using-powershell.aspx

______________________________________________________________________________

Sample Script

Thanks is in store to Colin at MSFT for taking the cmdlets above and throwing together a great sample script.   Copy the script below and save it as a .PS1 file.

Note:  When provisioning a search service application for hosted “multi-tenant” sites, the following cmd-lets must contain the –partitioned parameter.
  • New-SPEnterpriseSearchServiceApplication (Step 3 below)
  • New-SPEnterpriseSearchServiceApplicationProxy (Step 4 below)
 

Add-PSSnapin Microsoft.SharePoint.PowerShell

# 1.Setting up some initial variables.
write-host 1.Setting up some initial variables.
$SSAName = “ContosoSearch”
$SVCAcct = “Contoso\administrator”
$SSI = get-spenterprisesearchserviceinstance -local
$err = $null

# Start Services search services for SSI
write-host Start Services search services for SSI
Start-SPEnterpriseSearchServiceInstance -Identity $SSI

# 2.Create an Application Pool.
write-host 2.Create an Application Pool.
$AppPool = new-SPServiceApplicationPool -name $SSAName”-AppPool” -account $SVCAcct

# 3.Create the SearchApplication and set it to a variable
write-host 3.Create the SearchApplication and set it to a variable
$SearchApp = New-SPEnterpriseSearchServiceApplication -Name $SSAName -applicationpool $AppPool -databasename $SSAName”_AdminDB”

#4 Create search service application proxy
write-host 4 Create search service application proxy
$SSAProxy = new-spenterprisesearchserviceapplicationproxy -name $SSAName”ApplicationProxy” -Uri $SearchApp.Uri.AbsoluteURI

# 5.Provision Search Admin Component.
write-host 5.Provision Search Admin Component.
set-SPenterprisesearchadministrationcomponent -searchapplication $SearchApp  -searchserviceinstance $SSI

# 6.Create a new Crawl Topology.
write-host 6.Create a new Crawl Topology.
$CrawlTopo = $SearchApp | New-SPEnterpriseSearchCrawlTopology

# 7.Create a new Crawl Store.
write-host 7.Create a new Crawl Store.
$CrawlStore = $SearchApp | Get-SPEnterpriseSearchCrawlDatabase

# 8.Create a new Crawl Component.
write-host 8.Create a new Crawl Component.
New-SPEnterpriseSearchCrawlComponent -CrawlTopology $CrawlTopo -CrawlDatabase $CrawlStore -SearchServiceInstance $SSI

# 9.Activate the Crawl Topology.
write-host 9.Activate the Crawl Topology.
do
{
$err = $null
$CrawlTopo | Set-SPEnterpriseSearchCrawlTopology -Active -ErrorVariable err
if ($CrawlTopo.State -eq “Active”)
{
$err = $null
}
Start-Sleep -Seconds 10
}
until ($err -eq $null)

# 10.Create a new Query Topology.
write-host 10.Create a new Query Topology.
$QueryTopo = $SearchApp | New-SPenterpriseSEarchQueryTopology -partitions 1

# 11.Create a variable for the Query Partition
write-host 11.Create a variable for the Query Partition
$Partition1 = ($QueryTopo | Get-SPEnterpriseSearchIndexPartition)

# 12.Create a Query Component.
write-host 12.Create a Query Component.
New-SPEnterpriseSearchQueryComponent -indexpartition $Partition1 -QueryTopology $QueryTopo -SearchServiceInstance $SSI

# 13.Create a variable for the Property Store DB.
write-host 13.Create a variable for the Property Store DB.
$PropDB = $SearchApp | Get-SPEnterpriseSearchPropertyDatabase

# 14.Set the Query Partition to use the Property Store DB.
write-host 14.Set the Query Partition to use the Property Store DB.
$Partition1 | Set-SPEnterpriseSearchIndexPartition -PropertyDatabase $PropDB

# 15.Activate the Query Topology.
write-host 15.Activate the Query Topology.
do
{
$err = $null
$QueryTopo | Set-SPEnterpriseSearchQueryTopology -Active -ErrorVariable err -ErrorAction SilentlyContinue
Start-Sleep -Seconds 10
if ($QueryTopo.State -eq “Active”)
{
$err = $null
}
}
until ($err -eq $null)

Write-host “Your search application $SSAName is now ready”

Microsoft-SharePoint Products-Shared/Operational – InfoPath Forms Services – Event ID 5567: The remote server returned an error: (401) Unauthorized

El día de hoy estuve trabajando en conectar un formulario de InfoPath basado en web con un servicio web nativo de SharePoint 2013 para poder cargar una imagen en una biblioteca de imágenes (http://server/_vti_bin/imaging.asmx). Al ejecutar el formulario como uno de tipo Windows la llamada al Web Service y las acciones se ejecutaron correctamente, sin embargo, al publicarlo en una biblioteca de formularios y ejecutar el mismo proceso desde la Web se presento el siguiente mensaje de advertencia.


 


De acuerdo al mensaje de error “(401) Unathorized”, la raíz del problema está relacionado con permisos al llamar y escribir información en la biblioteca. Revisé en Internet Information Services y verifiqué que el pool de aplicaciones “SharePoint Web Services Root” estaba operando con la cuenta “Local System”, modifiqué esta propiedad con una cuenta de usuario con permisos de escritura en la biblioteca, reinicié el pool de recursos y al probar nuevamente el formulario InfoPath Web funcionó todo adecuadamente.


ACTUALIZACIÓN:


En una primera instancia la solución planteada corrigió el problema, sin embargo y luego de unos momentos el problema se presentó nuevamente. Como se plantea en algunos sitios la solución no está en configurar la clave de registro “DisableLoopbackCheck” sino el tema es más por el llamado que hace InfoPath a los web services de SharePoint, ya que nativamente cuando se utiliza un formulario Windows funciona todo bien y es porque utiliza las credenciales del computador sin embargo en formularios web les recomiendo seguir los pasos descritos en este enlace http://www.pointgowin.com/seethepoint/Lists/Posts/Post.aspx?ID=55.


 

Sharepoint List Adapters: The HTTP request is unauthorized with client authentication scheme ‘Ntlm’. The authentication header received from the server was ‘NTLM’.

En este caso estuve trabajando con el componente de CodePlex, SharePoint List Source and Destination (http://sqlsrvintegrationsrv.codeplex.com/releases/view/17652), que se integra con SSIS para gestionar los datos en las listas de sharepoint dentro de paquetes de ETL. En la consola de desarrollo de SSIS de forma repentina los paquetes que utilizan el Connection Manager de SharePoint generaron una advertencia:


Error: System.ServiceModel.Security.MessageSecurityException:
The HTTP request is unauthorized with client authentication scheme ‘Ntlm’.
The authentication header received from the server was ‘NTLM’.
—> System.Net.WebException: The remote server returned an error: (401) Unauthorized.


Al revisar algunos enlaces de referencia del error y el mensaje mismo, se identifico que la cuenta de usuario utilizada para conexión a Sharepoint, que utiliza por defecto el Connection Manager de Sharepoint de SSIS, estaba almacenada de forma errónea en el componente de administración de credenciales del sistema operativo. Se ejecutó el comando desde una ventana “Ejecutar… (run…):


rundll32.exe keymgr.dll,KRShowKeyMgr


Y se editó la credencial almacenada en el sitio de SharePoint. Se modificó tanto el nombre de usuario como la contraseña. Finalmente se cerró y abrió sesión nuevamente en el sistema operativo y SSIS con su paquete volvió a funcionar correctamente.


Referencias:

  • http://sqlstuff.weebly.com/ssis.html
  • http://support.microsoft.com/kb/555631/en-us


    Sharepoint 2010 – Consideraciones para la configuración del servicio de búsqueda

    El proceso de configuración del servicio de búsqueda en Sharepoint involucra los siguientes pasos generales:


    - Crear una cuenta de usuario, dominio o local, que tenga privilegios de acceso sobre todo el contenido de Sharepoint que se va a incluir en el proceso de indexación y búsqueda.


    - Con la cuenta de usuario creada, registrarla como cuenta administrada de Sharepoint.


    - Crear una aplicación de servicio de búsqueda, Search Service Application, en donde se crean las bases de datos respectivas y adicionalmente se registra la cuenta de servicio respectiva que debe ser la misma de los puntos anteriores.


    - Configurar las fuentes de contenido, content sources, de acuerdo a la configuración de los sitios de Sharepoint.


    - Ejecutar una tarea de “full crawling” sobre el contenido y verificar que la base de datos se ha alimentado con los registros encontrados.


    Ahora bien, cuando el sitio web es configurado con soporte para autenticación Windows (NTLM) y FBA, y adicional a esto fue configurado con un nombre diferente al configurado por defecto, por ejemplo intranet.midominio.com, el proceso varía. Me encontré con las siguientes novedades:


    - Por defecto cuando se configura la aplicación del servicio de búsqueda se agrega como fuente de contenido al URL que se encuenta configurada en la zona AAM como por defecto, en nuestro caso sería intranet.midominio.com.


    - Al intentar ejecutar la tarea de “full crawling” sobre esta configuración se puede presentar el siguiente error:


    The SharePoint server was moved to a different location. ( Error from SharePoint site: HttpStatusCode Found The request failed with the error message: <html><head><title>Object moved</title></head><body> <h2>Object moved to <a href=“%2f_LAYOUTS%2fSharePoint.POC%2fLogin.aspx%3fReturnUrl%3d%252f_vti_bin%252fsitedata.asmx”>here</a>.</h2> </body></html> –. )


    De acuerdo a algunos blogs revisados, para solucionar este problema se debería crear una regla de “crawl” que especifique la página personalizada de inicio de sesión (FBA) y adicionalmente las credenciales de acceso. En mi caso este proceso no funcionó.


    - Como alternativa adicional, en otros sitios, proponía extender el sitio con autenticación FBA + NTLM a un sitio que solo soporte NTLM, en mi caso por ejemplo intranet.midominio.com:555 sería el sitio extendido con soporte únicamente para autenticación -NTLM.


    - En la configuración de fuentes de contenido especificar este nuevo sitio, intranet.midominio.com:555.


    Al configurar estas opciones en efecto la tarea de “crawling” finalizó exitosamente y se indexaron todos los items del sitio, sin embargo, al probar el cuadro de búsqueda que se encuentra en la barra de navegación (superior derecha) y colocar una palabra para buscarla, la página de resultados no mostró resultado alguno.


    Para identificar el error procedí a habilitar los logs del servicio de búsqueda en nivel “verbose” y adicionalmente descargar la herramienta ULS Viewer (http://archive.msdn.microsoft.com/ULSViewer).


    Al revisar los archivos de log, posterior a hacer algunas pruebas de búsqueda para identificar el error, encontré el siguiente mensaje:



    Esto implica que aparentemente no existen “Query Processors” habilitados en la granja de Sharepoint para atender las búsquedas enviadas. En específico un Query Processor dentro de la granja de Sharepoint se habilita iniciando el servicio de “Search Query and Site Settings Service” en la sección “Services on Server”.



    Adicionalmente se debe habiliar la característica de colección de sitios “Elementos web de Search Server” en: Acciones del Sitio > Configuración del sitio > Administración de la colección de sitios > Características de la colección de sitios.


    Posterior a configurar estas opciones no hubo cambios, el cuadro de búsqueda no presentaba ningún resultado.


    Finalmente, en la página de administración de la aplicación del servicio de búsqueda, en la barra lateral izquierda, se encuentra la opción “Server name mappings” (http://altfo.wordpress.com/2010/07/08/this-site-this-list-sharepoint-search-not-working-or-returns-nothing/). En esta opción agregué un item con las siguientes opciones:


    - Address for indexing: http://intranet.midominio.com:555


    - Address for display in search results: http://intranet.midominio.com


    Ejecuté una nueva tarea de “full crwaling” y finalmente funcionó el cuadro de búsqueda y resultados.


     


    Otras referencias útiles:


    - http://blogs.msdn.com/b/russmax/archive/2010/04/23/search-2010-architecture-and-scale-part-2-query.aspx


    - http://blogs.msdn.com/b/russmax/archive/2012/02/15/guide-to-walking-a-sharepoint-2010-search-query-behind-the-scenes.aspx

    Sharepoint 2010 – Search Server – Removing the Search Service from the server must be done within the context of a Search Service Application …

    En resumen, al tratar de configurar el servicio de búsqueda en una granja de 3 servidores Sharepoint (DB, App, Web FE) el proceso no concluyó exitosamente y se crearon registros huérfanos del proceso. Al tratar de detener el servicio “SharePoint Server Search” se presentó el mensaje de advertencia:



    Para lograr detener completamente el servicio:


    - Obtener el ID de la aplicación de búsqueda: get-spserviceapplication


    - Eliminar la aplicación de Search con el comando: Stsadm -o deleteconfigurationobject -id “id del anterior paso”


    - Ingresar al sitio desde la Consola de Administración Central: http://server_sps:puerto/_admin/databasestatus.aspx, revisar si existen base de datos de la aplicación de Search que no fueron configuradas adecuadamente.



    - Eliminar los registros desde el command shell: $orphanedDB = Get-SPDatabase | where{$_.Name -eq “MySearchDatabase”} $orphanedDB.Delete()


    - Eliminar las bases de datos desde el SQL Server Management Studio.


    - Finalmente ejecutar el comando: stsadm -o osearch -action stop


     


     ——– ACTUALIZACIÓN ———– 28/10/2013


    Pude percatarme que podría darse el caso de que se mantengan aplicaciones en el sitio SharePoint Web Services relacionados con el servicio SearchService.svc. Para dejar complemetamente limpio el ambiente eliminar aquellos directorios virtuales que contengan el archivo SearchService.svc.

    Ejecución de un flujo de trabajo en múltiples items de una lista de Sharepoint

    En mi caso particular, tuve la necesidad de ejecutar un flujo de trabajo, construido con SPD, en cerca de 2500 items de una lista de Sharepoint. Luego de navegar por varios minutos encontré el script “Start-OSCSPWorkflow” basado en powershell el mismo que permite ejecutar un workflow sobre una cantidad de items determinada. De acuerdo a las recomendaciones del sitio es importante considerar la capacidad de procesamiento del servidor de Sharepoint para ejecutar cierta cantidad de flujos de trabajo. Para mi escenario, los 2500 items consumió un total de 1.5 GB de Memoria, mientras que el procesador casi no fue impactado de forma constante.


    Luego de hacer una importación del script es importante definir como se ejecutará el mismo, por ejemplo, con el parámetro -ItemID se puede colocar una lista de IDs de los items de la lista de Sharepoint que se van a ejecutar separados por comas (,).


    Start-OSCSPWorkFlow -SiteURL “Dirección_Sitio” -ListName “Nombre_Lista” -WorkflowName “Nombre_Workflow_SPD” -ItemID 12, 33, 45 -verbose


    El script por defecto acepta un máximo de 10 IDs de items de la lista. Esto lo controla con el parámetro -MaxConcurrentWorkflowNumber. Si se va a ejecutar más de 10 elementos deben colocar ejecutar el script con el parámetro -MaxConcurrentWorkflowNumber y un valor superior al de los IDs enviados.


    Existe otra forma de ejecución del script y es por medio de una consulta CAML. Si el objetivo es ejecutar un workflow sobre todos los items de una lista:


    Start-OSCSPWorkFlow -SiteURL “Dirección_Sitio” -ListName “Nombre_Lista” -WorkflowName “Nombre_Workflow_SPD” -Query ‘<FieldRef Name=”ID” />’ -verbose -MaxConcurrentWorkflowNumber 100


    He colocado el valor de 100 al parámetro -MaxConcurrentWorkflowNumber, por ejemplo, si la consulta CAML retorna menos de 100 elementos, caso contrario deben colocar un valor mayor.


    El URL de donde pueden descargarse el script es http://gallery.technet.microsoft.com/office/Start-a-Workflow-on-120bffe5, espero sea de su utilidad.


     

    Menú de Sharepoint 2010 con imágenes/animaciones flash

    Me encontré con un nuevo problema al publicar una animación flash en un sitio de Sharepoint. Resulta que el menú de Sharepoint se presenta detrás de la animación de flash, similar a la imagen presentada.



    Para publicar la animación flash utilicé un archivo HTML que hace el llamado a la animación flash y un webpart visor de páginas web para llamar a la página HTML. El truco está en cambiar la etiqueta HTML al siguiente valor:


    <param name=”wmode” value=”transparent”>


    Espero sea de su utilidad.

    Sharepoint 2010 Administration – Error al iniciar el servicio ID 7000 y 7009

    Al tratar de reiniciar el servicio “Sharepoint 2010 Administration” se presentó el mensaje de error:


    “The service did not respond to the start or control request in a timely fashion.”


    Luego de revisar algunos posts ejecuté el siguiente procedimiento:


    - ejecuté el comando stsadm -o localupgradestatus, para determinar si era necesaria la actualización de alguna base de Sharepoint. En efecto se presentó un mensaje indicando que la base de configuración requería ser actualizada.


    - Traté de ejecutar el comando “psconfig –cmd upgrade –inplace b2b –wait –force” sin tener suerte.


    - Traté también de ejecutar el comando “stsadm -o upgrade -forceupgrade”, igualmente sin tener suerte.


    - Ejecuté manualmente el asistente de configuración de productos de sharepoint y el mismo culminó sin éxito.


    - Se creó la clave de registro “ServicesPipeTimeout” de tipo DWORD en la sección “HKLM\SYSTEM\CurrentControlSet\Control”, con el valor decimal de 60000.


    - Actualicé la clave de registro “WaitToKillServiceTimeout” en la sección “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control” con el valor decimal de 120000.


    - Reinicié el servidor y ejecuté nuevamente el asistente de configuración de productos de Sharepoint, igualmente sin suerte.


    - Finalmente ejecuté el comando “psconfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures” y el procedimiento culminó sin problemas e inició el servicio igualmente.


    Espero sea de su utilidad.

    Sharepoint 2010 + Infopath 2010: The operation could not be completed

    En un formulario de Infopath, al crear una nueva conexión de extracción de datos, se presentó el siguiente mensaje de error:



    En mi escenario, se creó un solo sitio de Project Web Application y un sitio secundario con una biblioteca de formularios. El mensaje de error se presenta cuando no se encuentra creada una colección de sitios en el sitio raiz de IIS.


    Para solucionar el problema ejecutar el siguiente procesimiento:


    - Utilizar la consola de Administración Central de Sharepoint para crear una colección de sitios en el sitio raiz de IIS (Sitio Web por Defecto).



    - Crear nuevamente la conexión de recepción de información en el formulario de Infopath.


     


     


    Como siempre espero esta información sea de su utilidad.

    Sharepoint 2010 – Infopath 2010: Check-In y Check-Out automático de un formulario.

    Al igual que cualquier documento que puede ser abierto y modificado por varias personas, es importante controlar que solo una persona a la vez pueda tomar el control de un documento (desproteger) y realizar los cambios necesarios, asegurando que cualquier otro usuario que abra el mismo documento solo tenga una vista de lectura. Al finalizar el proceso de edición, el usuario que tomó el control debe grabar y cerrar el documento (proteger) de tal forma que otro usuario pueda tomar el control de mismo cuando lo requiera.


    Para el caso de los formularios de Infopath 2010, y sobre todo cuando trabajamos con un workflow relacionado a la biblioteca de formularios, es importante que este proceso de desprotección y protección sea transparente para el actor (usuario) de la actividad actual.


    Para lograr este objetivo hay que ejecutar los siguiente pasos:


    1. Crear dos conexiones relacionados a los servicios web Checkoutfile y Checkinfile. Ambos servicios web los expone directamente Sharepoint.


     


     


     


    Algunos enlaces importantes:


    http://www.infopathdev.com/blogs/mel_balsamo/archive/2011/05/15/create-an-xtp-to-check-in-and-check-out-forms-using-udc-files.aspx


    http://www.infopathdev.com/forums/p/16360/61173.aspx


    http://www.infopathdev.com/forums/t/7603.aspx

    Just another Microsoft MVPs site