El servicio de Sincronización de Perfiles se queda pillado en "iniciando"

Esto viene a raíz de querer hacer una sincronización de perfiles de usuarios pero encontrarnos con que el servicio de sincronización no arrancaba, se quedaba pillado en "iniciando" o "starting".

Hagamos una traducción al inglés:

User Profile Service Stuck on Starting.

Cuando en la Central de Administración vamos a "servicios en el servidor" o "services on server" y vemos que el servicio de sincronización no termina nunca de arrancar, podemos pasar este script para desaprovisionarlo:

Add-PSSnapin Microsoft.SharePoint.Powershell
$TypeName = “User Profile Synchronization Service”
$ServerName = “SERVERNAME” #Replace with your server name where the service is stuck on Starting
$Serviceinstance = Get-SPServiceInstance | where-object {$_.TypeName -eq $TypeName -and $_.Server.Address -eq $ServerName}
$Serviceinstance.Unprovision()



Después, volvemos a servicios en el servidor y lo inicialmos de nuevo para que aprovisione bien.

Se han creado alertas correctamente, pero estos usuarios no recibirán notificaciones por correo electrónico hasta que se proporcionen direcciones válidas.

A nosotros el paciente nos alertó en inglés, algo de que no escuchaba bien, venía con serios problemas en el tímpano:

Alerts have been created successfully but these users will not receive notifications until valid e-mail or mobile addresses have been provided.

Pero para el caso es lo mismo, al intentar crear una alerta a un usuario concreto en un elemento de lista o biblioteca, aparece el siguiente mensaje:

Solucionamos el problema yendo al servicio de perfiles de usuario a realizar una sincronización, pero vimos que la sincronización de perfiles de usuario no estaba aprovisionada, para resolver esto vamos a servicios en el servidor e iniciamos el servicio de sincronización de perfiles.

Ahora, vamos al servicio de perfiles de usuario y una vez haya terminado el aprovisionamiento, haremos una sincronización COMPLETA o full sync, en la imagen a continuación, el aprovisionamiento aún no ha terminado.

Una vez terminada la sincronización, podemos observar si la cuenta tiene o no correo electrónico, hacemos clic en Manage User Profiles o Administrar Perfiles de Usuario y buscamos, como podemos observar, no tenemos correo, en otro caso, podríamos dar por resuelto el problema:

Esto se debe a que la cuenta no tiene en Directorio Activo un email asignado o bien a que la cuenta es de Office 365 y no cuenta con sincronización on-premise, no hay problema, el servicio de perfiles permite que nosotros asignemos un correo electrónico a la cuenta, para ello hacemos clic en la cuenta en la columna Account name (en la imagen de arriba) y elegimos en el combo la opción editar, después asignamos una dirección de correo electrónico y guardamos y cerramos (botón arriba y abajo de la página):

Por último, volvemos a hacer una sincronización completa, por alguna extraña razón que no nos hemos parado a destripar (aún), no sirve aparentemente las sincronizaciones incrementales.

Si todo va bien, podremos recibir alertas en esta cuenta sin problemas.

Voracidad de Search afecta a los Workflows de Project Server. HTTP 500 The requested service, xxx could not be activated.

"Cuando una mariposa agita sus alas en Nueva Zelanda, alguien se come un puñado de garbanzos torraos en Albacete".

O algo así decía el refrán creo recordar, pero viene a cuento por la extraña sucesión de causas encadenadas de hoy.

Nuestro paciente venía aquejado de errores en un flujo intestinal de trabajo, el cual daba un error para algunos proyectos que se quedaban bloqueados, uno de estos diversos errores que los workflows de Project se afanan, con mucha creatividad siempre, en producir:

RequestorId: dd6ae4d8-59fc-a419-0000-000000000000. Details: An unhandled exception occurred during the execution of the workflow instance. Exception details: System.ApplicationException: HTTP 500 The requested service, 'http://es1intra02v:32843/32dbfb0876734f6493e48270df96c4cf/AppMng.svc' could not be activated. See the server's diagnostic trace logs for more information. {"SPRequestGuid":["dd6ae4d8-59fc-a419-8ae7-fb670df49745"],"request-id":["dd6ae4d8-59fc-a419-8ae7-fb670df49745"],"X-FRAME-OPTIONS":["SAMEORIGIN"],"SPRequestDuration":["9294"],"SPIisLatency":["0"],"MicrosoftSharePointTeamServices":["15.0.0.4569"],"X-Content-Type-Options":["nosniff"],"X-MS-InvokeApp":["1; RequireReadOnly"],"Date":["Tue, 12 Jul 2016 10:04:41 GMT"],"Server":["Microsoft-IIS\/8.5"],"X-Powered-By":["ASP.NET"]} at Microsoft.Activities.Hosting.Runtime.Subroutine.SubroutineChild.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

En negrita dejo lo importante del asunto, y lo importante no es que ese servicio falle, si no que un servicio falla con "could not be activated", investigando un poquito en el vademecum google, hallamos que la caída de servicios con un "could not be activated" suele estar íntimamente relacionada a la falta de recursos en el servidor.

Efectivamente, así era:

Memoria, casi a tope.

Disco duro, como vimos en otro post, no respeta la recomendación de Microsoft de mantener libre en disco al menos el doble de la memoria RAM instalada.

Task Manager, indicando que el proceso noderunner.exe, el encargado de dar vida al sistema Search de SharePoint, estaba siendo un elemento voraz con los recursos:

El fonendoscopio Health Analyzer, nuestro sempiterno amigo que llevamos siempre colgado del cuello:

Para salir del embrollo por ahora, bastó con reiniciar los servicios de Windows SharePoint Search y Host Controller:

Y reiniciar los workflows que estaban dando problemas desde la configuración de PWA en "Change or restart workflows", causando a los usuarios la molestia de comenzar de nuevo con los flujos, el menor de los males en estos casos.

Debido a que esto es pan para hoy y hambre para mañana, se ha echado la bronca recomendado al cliente que aumente los recursos de sus máquinas, poniendo unos 40 o 50 GB más de disco duro en cada servidor como mínimo tanto en los servidores SharePoint como en el de SQL Server, donde además debería echar un vistazo al crecimiento de las bases de datos, y que aumente la RAM hasta los 24 GB, para evitar que esto se siga repitiendo.