jueves, 24 de marzo de 2016

Cómo modificar un atributo de UPS para un usuario concreto desde PowerShell

Hoy he estado utilizando este script que me ha sido muy útil para chequear y modificar diversos atributos directamente del User Profile Service, usando una secuencia de comandos PowerShell

Las líneas en rojo las usaríamos únicamente en caso de querer añadir o modificar dicho atributo en el perfil buscado. Si únicamente queréis ejecutar una consulta, eliminad directamente esas líneas.

$mySiteUrl = "https://MySiteHostURL/"
$adAccount = "domain\useraccount"
#Replace the next attribute name with the one you want to search
$upAttribute = "WorkPhone"
#The value you want to add to the profile
$upAttributeValue = “+417648399”

#Get site objects and connect to User Profile Manager service
$site = Get-SPSite $mySiteUrl
$context = Get-SPServiceContext $site
$profileManager = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($context)

#Check to see if user profile exists
if ($profileManager.UserExists($adAccount))
{
    #Get user profile and change the value
    $up = $profileManager.GetUserProfile($adAccount)
    #Show the current attribute value
    write-host "Current attribute value is: "up[$upAttribute].Value
    #Use the next two lines only if you really want to add/replace the $upAttribute info in the UPS
    $up[$upAttribute].Value = $upAttributeValue   
    $up.Commit()
}
else
{
    write-host "Profile for user"$adAccount "cannot be found"
}

#Dispose of site object
$site.Dispose()

Eso es todo. A veces es mucho mejor para nuestras pruebas o verificaciones tener preparado un pequeño script en PowerShell que no tener que movernos tediosamente por las pantallas de la Administración central (Ir al servicio UPS, ir a la pantalla de búsqueda de perfiles, realizar la búsqueda, abrir el perfil, encontrar la información...).

Deseando que le sea útil a alguien,
¡Un saludo!

miércoles, 23 de marzo de 2016

Cómo forzar la parada de un servicio.

En ocasiones, si somos administradores de SharePoint, nos encontraremos que algún servicio que hemos intentado arrancar en algún servidor, se queda eternamente en estado "Starting", sin llegar nunca a finalizar su puesta en marcha, y sin darnos la opción de pararlo tampoco desde la interface de la Administración central: Application Management  --> Service Applications --> Manage services on server.


El por qué se quedan colgados estos servicios, y cómo evitar ese comportamiento puede ser un post muy largo que no abarcaré hoy, sin embargo sí que explicaremos cómo se puede forzar la parada de un servicio. Como siempre, PowerShell acude a nuestro rescate.

Lo primero que tendremos que hacer es encontrar el ID del servicio que se ha quedado colgado. Para ello podemos abrir una consola de PowerShell en alguno de nuestros servidores de la granja de SharePoint (siempre en modo Administrador) y escribir el siguiente comando:

Get-SPServiceInstance > Services.txt

Esto nos generará un fichero txt con los detalles de todos los servicios (en la pantalla de la consola habría demasiado espacio como para listarlos todos).

Si abrimos el fichero resultante (con NotePad, por ejemplo), podremos buscar el nombre del servicio que queremos parar (en mi caso "User Profile Synchronization Service"). Una vez lo hayamos localizado, tendremos que anotar el valor del campo "Id" que aparecerá más abajo.


Y ya sin mas, podemos regresar a nuestra consola de PowerShell y ejecutar el comando Stop-SPServiceInstance, con el parámetro del ID que hemos copiado de nuestro fichero.

Stop-SPServiceInstance a192794c-f987-4a26-8a17-25a8e33df879

Antes de ejecutarse, nos pedirá confirmación (pulsamos 'y').


Una vez hecho esto, veremos que nuestro servicio se ha detenido correctamente.


A partir de aquí podemos intentar arrancarlo de nuevo, o realizar las acciones necesarias para evitar que se vuelva a quedar colgado antes de un nuevo reintento.

¡¡Un saludo!!

miércoles, 16 de marzo de 2016

Cómo forzar la opción de "guardar sitio como plantilla"


Hay ocasiones en las que queremos guardar un sitio como plantilla, para migrarlo de entorno o ser capaz de crear más como él mismo, pero la opción que se supone debería estar en Site Settings- Site Actions - Save site as template está oculta (generalmente si hemos habilitado la característica de "Publicación").

¿Podemos guardar el sitio como plantilla en estos casos?

Existe un procedimiento para saltarnos esta casuística de SharePoint (lo cual suena algo absurdo, lo sé, ojalá no tuviéramos que andar con triquiñuelas para lograr estas cosas, pero de momento es lo que hay).

En primer lugar lanzaremos nuestro querido SharePoint Designer, y abriremos en él sitio en cuestión.

Una vez el sitio esté cargado, iremos a la pantalla principal, la que tiene la información básica del sitio, y en la Ribbon pulsaremos sobre "Opciones de sitio"


En el panel que se abrirá realizamos las siguientes acciones:

  1. Seleccionamos el parámetro "SaveSiteAsTemplateEnabled"
  2. Pulsamos en el botón de "Modificar..."
  3. cambiamos el valor de "false" a "true"
  4. Pulsamos en el botón de Aceptar.
  5. Pulsamos en el botón de Aceptar.



También podríamos ejecutar el mismo paso directamente con PowerShell y evitando SharePoint Designer, ejecutando el siguiente script:

$web = Get-SPweb "https://AppWebURL/sites/SiteCollection/Subsite"
$web.SaveSiteAsTemplateEnabled = $true;
$web.Update();

Una vez hecho esto, tan solo queda acceder a la página de administración que permite guardar el sitio como plantilla.

En caso de que continúe sin aparecer en nuestra pantalla de Site Settings, siempre podemos acceder directamente añadiendo la coletilla "/_layouts/15/savetmpl.aspx" a la URL de nuestro site en el navegador.

http://AppWebURL/sites/SiteCollection/Subsite/_layouts/15/savetmpl.aspx



¡¡Voila!!

The request uses too many resources

Ayer estuve trabajando en un flujo de trabajo que ha de crear un subsite en una URL determinada. La acción es relativamente sencilla de configurar con Nintex Workflow, así que mi sorpresa fue mayúscula cuando el flujo de trabajo retornó un error. El mensaje que mostraba era:

"The request uses too many resources".

Así que, como es habitual en nuestro trabajo tuve que indagar y rebuscar en la red, hasta que encontré la forma de solucionarlo.

Básicamente se trata de aumentar la capacidad de nuestra aplicación web para tratar con este tipo de instrucciones, mediante un sencillo script en PowerShell.

Para proceder, abriremos una consola de "SharePoint 2013 Management Shell" en modo Administrador.

Ejecuntando la siguiente línea, podremos observar el valor de los parámetros "MaxObjectPaths" y "ClientCallableSettings" para las diversas aplicaciones web de nuestra granja:

 Get-SPWebApplication | %{$_.ClientCallableSettings}


Ahora introducimos las siguientes líneas para aumentar esos valores (bajo vuestra responsabilidad y riesgo, ignoro si existe algún efecto colateral a esto).

 $webApp = Get-SPWebApplication "http://RootWebAppURL/"
 $webApp.ClientCallableSettings.MaxObjectPaths = 3000
 $webApp.ClientCallableSettings.ClientCallableSettings = 3000
 $webApp.Update()

Una vez ejecutado el sencillo script, si volvemos a introducir la primera instrucción, comprobaremos que realmente los valores de nuestra AppWeb han cambiado:


Ahora nuestro workflow ya no debería darnos problemas al intentar crear un subsite...

¡Saludos!