martes, 24 de febrero de 2015

Alternativas para autenticarse por Windows desde una granja de SharePoint migrada en Azure

Hay muchas aclaraciones que hacer con este tema, pero seré lo más conciso posible yendo al grano y resolviendo algunos mitos o malas concepciones sobre el tema.

Primero lo primero, definir el requerimiento del cliente.  Mover  la granja de SharePoint hacia la nube de permitiendo a los usuarios de la red interna o intranet autenticarse con sus mismas credenciales de su red interna en la instancia de Azure.

En este escenario hay un componente que define las opciones que tenemos disponibles y las que no.  A continuación las opciones disponibles en Azure hoy 14 de Febrero del 2015.  Ya que Azure evoluciona tan rápido que mejor hago referencia a la fecha en como estaban las cosas en ese momento.   Para las tres opciones es necesario establecer una VPN sitio a sitio entre Azure y la red interna del cliente.  Esto nos permite ver la red interna del cliente desde las Virtuales de Azure y viceversa como que si estuviésemos en la misma ubicación geográfica.  Entonces los servidores se configuran como el resto de servidores de la red interna, y perteneciendo al dominio o bosque al que se le indique en la configuración.  Las cuentas de servicio utilizadas en la instalación son del dominio de la intranet así que gracias al tunel privado de la VPN las dos redes son una misma red.  En Azure se crearon dos Virtuales una con SQL Server y otra con SharePoint Foundation 2013.  Se montó la base de datos de contenido de la granja local al ambiente creado en Azure.

Explicado eso enumeramos las 3 opciones posibles de configuración:

1) La autenticación de Windows sucede en el DC de la intranet a través de la VPN, si por alguna razón la VPN se interrumpe, los usuarios no podrán autenticarse a los servidores que están en Azure ni desde la red interna ni desde Azure.   https://msdn.microsoft.com/en-us/library/azure/dn636917.aspx

Resultado de imagen para vpn connection azure

2) Se adiciona otra virtual donde se configura el rol de Controlador de Dominio y se utiliza el AD Directory Service para definir un sitio en Azure basado en el rango de IPS definidas en la VPN sitio a sitio.  Esto permite que los usuarios se autentiquen con el DC configurado en Azure y en caso se pierda la conexión de la VPN los usuarios que accedan desde internet puedan autenticarse al SharePoint que esta en Azure, no así los de la intranet si utilizan el descubrimiento del DNS local sino el público con un enlace de Internet.  Esto da una mayor independencia de acceso con algunos inconvenientes. http://azure.microsoft.com/en-us/documentation/articles/virtual-networks-install-replica-active-directory-domain-controller/

https://msdn.microsoft.com/library/azure/jj156090.aspx

3) Se implementa AD FS o Active Directory Federation Service en azure, para ello se requiere como mínimo para menos de 1,000 usuarios tres servidores virtuales adicionales uno para AD FS y otro para AD FS Proxy o WAP (Web Application Proxy) y otro para DirSync.  Si son más de 1,000 usuarios se recomienda redundancia en los servidores AD FS, es decir para dar un total de 5 servidores.  Para esta ultima configuración se recomienda que el o los DC´s corran por lo menos sobre Windows 2008 R2 y utilizar el asistente de configuración el Azure AD Connect que aunque este en Preview, facilita la configuración de estos servidores.   Esta última opción es una solución Single Sign On real, que permite autenticar a los usuarios tanto de la red interna como la nube aunque la VPN falle.  Solo fallará si el enlace a internet no esta disponible desde donde se este accediendo.

https://technet.microsoft.com/en-us/library/hh831502.aspx

https://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=53949

https://technet.microsoft.com/en-us/library/dn296436.aspx

http://simon-may.com/adfs-dirsync-waad-resources/

El escenario no disponible para resolver este problema es el siguiente:

Configurar un servidor virtual en Azure para sincronizar el directorio Activo local al Directorio de Azure.  Este escenario no funcionará ya que el contenido migrado tiene los permisos asignados a los usuarios de la red interna que están registrados en SharePoint con el formato tradicional de usuario de red [dominio]/[nombre usuario] y los usuarios del Directorio de Azure son reconocidos con el siguiente formato [Proveedor Azure]:[Nombre de Usuario en formato upn].  Además los usuarios de red utilizan el siguiente prefijo en el formato i:0#.w y los usuarios autenicados por el Directorio de Azure con el siguiente prefijo: i:0e.t .  (Dando a entender que el primero es Windows y el segundo externo). Este escenario esta pensado para usuarios externos que deseamos exponer información que vamos a compartir con ellos, por ejemplo proveedores, clientes o socios de negocios.

https://msdn.microsoft.com/en-us/library/azure/dn441214.aspx

https://technet.microsoft.com/en-us/library/dn635311.aspx

 

Que escenario escoger es dependiendo que tan crítico es la información almacenada en SharePoint y que tanto se desea invertir para mantener la disponibilidad del servicio todo el tiempo para los usuarios de la red de la organización para acceder dicho servicio tanto desde la red interna como del internet.

En este artículo vimos 3 escenarios para acceder la plataforma de SharePoint desde la nube pero autenticándonos con  los usuarios de la red interna lo que podemos catalogar como un ambiente híbrido. 

Les recomiendo revisen el siguiente artículo:

Planning for SharePoint 2013 on Azure Infrastructure Services

The SharePoint Server Farm feature

Hasta la próxima!,

Juan Manuel Herrera Ocheita

jueves, 19 de febrero de 2015

Cómo sincronizar los usuario y contraseñas locales con Azure AD para una instancia nueva de SharePoint 2013

El escenario es el siguiente:

Se desea crear una instancia nueva de una granja de SharePoint 2013 en la nube de Azure para reducir los costos de operación e inversión, el cliente solicita que los usuarios de su red interna puedan autenticarse con sus mismas credenciales en y con la mínima configuración posible.

Cuales son los requerimientos básicos entonces para este escenario:

1) Contar con una suscripción en Azure

2) Contar con una Directorio Activo Local

3) Realizar una Conexión VPN Sitio a Sitio desde el portal de Azuren

4) Una Virtual con Windows Server y AD DirSync para sincronizar los usuarios de la red interna con el Directorio Activo de Azure

5) Dos Virtuales conectadas al dominio local por medio de la VPN para SQL Server y SharePoint 2015

6) Configurar la Aplicación Web en SharePoint para utilizar el Directorio Activo de Azure como proveedor de autenticación

NOTA: Este escenario es valido si no se esta migrando contenido de SharePoint de la red interna a la nube de Azure, ya que a nivel de permisos en SharePoint el usuario de Windows la red interna se registra de otra forma distinta a la del proveedor de Azure.  El formato tradicional de usuario de red en SharePoint se registra de la siguiente forma: [dominio]/[nombre usuario] (Ej: midominio\elusuario) y los usuarios del Directorio de Azure son reconocidos con el siguiente formato [Proveedor Azure]:[Nombre de Usuario en formato upn] (Ej.: [Proveedor Azure]miusuario@midominio.com).  Además los usuarios de red utilizan el siguiente prefijo en el formato i:0#.w y los usuarios autenticados por el Directorio de Azure con el siguiente prefijo: i:0e.t .  (Dando a entender que el primero es Windows y el segundo externo).

Que beneficios nos provee Azure como plataforma.  Pues son muchos pero entre los que más se agradece son los siguientes:

1) Azure solo cobra por uso, es decir si tengo reservado un espacio de almacenamiento no me cobra por ello solo el  que ocupo.  No me cobra por la VM mientras este apagado por ejemplo.  O la VPN solo cuando este trasfiriendo paquetes de un lado a otro.

2) Se cuenta con IP públicas por cada máquina virtual y nombres públicos accesibles desde el internet

3) Una vez familiarizado con el portal y sus opciones, es relativamente fácil la configuración del ambiente y la seguridad, como por ejemplo habilitar o deshabilitar el acceso a las virtuales por Escritorio Remoto, HTTP, IMAP, etc.

4) Contar con Servicio de Directorio Activo disponible de forma inmediata, para utilizar como proveedor de autenticación en una granja de SharePoint.

Resumen del procedimiento

1) Adquirir una suscripción en Azure http://azure.microsoft.com/en-us/pricing/free-trial/

image

2) Establecer una VPN sitio a sitio https://msdn.microsoft.com/es-es/library/azure/dn636917.aspx

Topología de red

La idea fundamental de la VPN este establecer un tunel privado en Internet para conectar las dos redes (local/nube).   Para ellos es necesario de lado del cliente contar con un Equipo de enrutamiento de Red o Router. Es necesario para configurarlo asignar IPs de lado de Azure que no colisionen con el rango de IPs de la red interna y que el rango asignado de ambos lados sea el mismo.  Es muy importante en esta configuración manejar la misma máscara supongamos que en el ejemplo de arriba estamos usando al configuración 192.168.1.0/24 eso define una máscara de IP por lo que de lado de Azure debemos manejar la misma máscara es decir 192.168.2.0/24.  El rango de IP locales configuradas deberán contener las IPS donde están los servidores DC y DNS ya que más tarde se utilizaran para conectar las virtuales a ese dominio.  Para configurar la VPN Ambos tienen que conocer las puertas de enlaces, rangos de IPs y la llave Pre-Shared, y la información de ambas fases.  Por ejemplo: 

Puerta de enlace intranet es en el ejemplo de arriba 192.168.1.11 y de lado de Azure es  192.168.2.11.

Fase I

authentication:  pre-share

encryption: aes-256

hashing: hash sha

Key group: Deffi

lifetime: 28800

Fase II – Configuración IPSEC

esp-aes-256 esp-sha-hmac

lifetime seconds 3600

lifetime kilobytes 102400000

La información de las fases es extraída del script generado para los dispositivos como CISCO en el siguiente enlace:

image

Si es exitosa veras una imagen similar a la de abajo.

image

3) Establecer un grupo de afinidad geográfico para asociar máquinas virtuales.  Esto es importante para reducir el tiempo de retraso por la ubicación geográfica y para que las maquines se puedan ver entre ellas.

image

4) Una Virtual con Windows Server y AD DirSync para sincronizar los usuarios de la red interna con el Directorio Activo de Azure

Importante en este procedimiento es crear una cuenta de servicio en Azure AD y asignarle el permiso de Global Admin. Eso lo hacemos en la edición del perfil del usuario dentro del Active Directory de Azure como se muestra en la imagen de abajo.

image

Directory sync with password sync scenario

Para revisar los prerrequisitos de Azure Dir Sync el siguiente enlace:

https://msdn.microsoft.com/en-us/library/azure/jj151831.aspx?f=255&MSPPError=-2147217396

 

5) Crear las máquinas virtuales  http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-tutorial/

image

Para crear las máquinas virtuales tenemos dos opciones de la galeria de Azure o bien de una imagen que hayamos subido.   En mi caso fue de una imagen que subimos ya que el cliente tenía su licencia de Windows.  Para ello fue necesario crear la virtual en Hyper-V instalar el sistema operativo del cliente y ejecutar la utileria sysprep para poder subir el archivo vhd, el resto del software lo podemos descargar vía suscripción desde el internet disponible en Azure luego de leventar la virtual.  El procedimiento para subir la vitual es la siguiente:

http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-create-upload-vhd-windows-server/

6) Configurar la Aplicación Web en SharePoint para utilizar el Directorio Activo de Azure como proveedor de autenticación

Users authenticated with Azure Active Directory

Para realizar esta configuración los dejo con tres enlaces que los ayudarán.  Lean los detenidamente y que no se les pase ningún detalle.  Mucho ojo con los FQDN y URL que deberán indicar ya que allí pueden tener problemas, puede eliminar y crear de nuevo las reglas de grupo el Proveedor de Identidad WS-Federation o el certificado, sin problema, solo asegúrense de hacerlo bien.

Oficial de Microsoft:

https://technet.microsoft.com/en-us/library/dn635311(v=office.15).aspx

Artículo de Fuse Collaboraton services

http://www.fusecollaboration.com/fuseblog/Lists/Posts/Post.aspx?List=178d823a-3196-48e8-bb8f-743bfee59281&ID=74&Web=8df942bb-1ca5-4306-9004-53a7757edbb8

Y de Patterns & practices

https://msdn.microsoft.com/en-us/practices/dn635311(v=office.14)

En este artículo vimos como configurar un pequeña granja de SharePoint pero en la nube de Azure, una tendencia cada vez más común dentro de las organizaciones.

Hasta la próxima,

Juan Manuel Herrera Ocheita

domingo, 8 de febrero de 2015

SharePoint Server 2016 para el segundo semestre de este año

El anuncio a dejado una esperanza para mejora y sorpresa al mismo tiempo.  Ya que InfoPath continua vigente para esta próxima versión y será totalmente soportado en  SPO o SharePoint Online.

Dos aspectos sobresalientes del anuncio son prometen más poder a la comunidad de desarrolladores que es de 3 millones de personas.   A través de las APIs ya disponibles y otras nuevas que serán presentadas.  El modelo de Apps continua contrario a lo que algunos piensan.

Y el tema Ambientes híbridos que es la mejor forma de acoger la idea de la nube y del software como servicio.

 

Main graphic - new - 020215

También parece ser que las características de seguridad mejoraran finalmente esperemos un tablero que facilite la seguridad y revisión de los permisos para apoyar la administración de SharePoint.  Esperemos ver asistentes de configuración como las nuevas herramientas de Azure que ayudan la instalación de escenarios más rápida y fácilmente, como lo es AAD Connect http://connect.microsoft.com/site1164/program8612.

Quieres leer más al respecto aquí enlaces:

http://blogs.office.com/2015/02/02/evolution-sharepoint/

http://redmondmag.com/blogs/the-schwartz-report/2015/02/on-premises-sharepoint-2016.aspx

Hasta la próxima!,

 

Juan Manuel Herrera Ocheita

viernes, 30 de enero de 2015

Error OMS_6118 al intentar crear una suscripción en Azure para virtualizar SharePoint

El proyecto es tener una granja de SharePoint en Azure en un ambiente hibrido donde los usuarios de la red interna se puede autenticar en el portal de SharePoint con sus cuentas de Windows.

El problema que tuvimos fue que los créditos de Azure se compraron por licenciamiento Open y la cuenta registrada en Azure al momento de adicionar la suscripción daba el siguiente error:

Sorry, we could not complete the operation. Please try again later or reload the web page [OMS_6118]

La clave de la solución me la dio el sugiente comentario en el foro:

“I was having the same issue, tried about 20 times with no luck. But first time I checked the "Microsoft can contact me for marketing purposes" checkbox, I got my subscription created.”http://answers.flyppdevportal.com/categories/azure/azurebilling.aspx?ID=5ff93290-f7b0-4b2f-9b03-097e17dfc6c4

Al parecer el problema esta con la cuenta que estamos utilizando para agregar la suscripción en Azure.  Las cuentas de empresas se deben de registrar en el sistema de identidades de Microsoft como lo es live.com, y este a su vez se asocia a Azure.

La solución:

Sabiendo de antemano esto, ingrese a www.live.com y me autentique con la cuenta y sorpresa me dio la bienvenida (es decir el usuario nunca había ingresado a live.com a revisar su perfil). 

image

Valide el tema de aceptar correos y lo volví a guardar.   Regrese a Azure e intente de nuevo el mismo procedimiento y adivinen que paso… funcionó! Guiño

image

Eso es todo a partir de ello pudimos empezar a trabajar con la creación de la VPN para comunicar el ambiente local (On Premises) y de la Nube o sea Azure.

Así que SharePonit vive en Azure también en un ambiente híbrido con muchas posibilidades para crecimiento y escalabilidad.

Hasta la próxima!,

Juan Manuel Herrera Ocheita

jueves, 15 de enero de 2015

Los roles de la autenticación por formularios pareciera no funcionar en SharePoint 2013

 

La autenticación por formularios en SharePoint existe desde la versión 2007 y es la respuesta de Microsoft para proveer otra forma de autenticación que no sea a través del Directorio Activo.  Este método de autenticación a evolucionado con las versiones más recientes de SharePoint y se ha convertido en una implementación más de la autenticación basada en reclamos permitiendo al administrador de IT o consultor de SharePoint personalizar el método de autenticación elegido de forma muy flexible.

En este artículo resolveremos el acertijo porque no funciona el rol de FBA dentro de un grupo de SharePoint y cual es la aplicación correcta.

En la imagen de abajo muestra el flujo de autenticación de una implementación por formularios.  Fundamentalmente el usuario navega a la URL del sitio de SharePoint y al momento de autenticarse es redirigido a una página aspx donde le solicita el usuario y la contraseña esta solicitud es trasladada al servicio en SharePoint para autenticar los usuarios el cual es conocido como Security Token Service o STS este valida el tipo de autenticación que en este caso es Autenticación basada en Reclamos y en una implementación de Formularios el cual conoce que su proveedor de membresía es una base de datos en SQL Server y allí valida que exista el usuario, que sea valida su contraseña y luego si es válida pasa al proceso de autorización sino lo es es rechazada la solicitud.

Forms-based authentication process

La implementación del repositorio de credenciales en la autenticación por formularios es a través de una implementación de base de datos denominada ASP.NET membership and role providers.  Dentro del esquema de base de datos se almacena los usuarios y los roles y la combinación de ambos. 

Expanded aspnetdb_claim node

Podemos concluir que los Roles es una forma de agrupar los usuarios dentro de esta implementación. 

EXEC aspnet_Roles_CreateRole 'MyAppName', 'Employee'
EXEC aspnet_Roles_CreateRole 'MyAppName', 'TeamManager'
EXEC aspnet_Roles_CreateRole 'MyAppName', 'CEO'

EXEC aspnet_UsersInRoles_AddUsersToRoles 'MyAppName', 'bob', 'Employee', 8
EXEC aspnet_UsersInRoles_AddUsersToRoles 'MyAppName', 'mary', 'TeamManager', 8
EXEC aspnet_UsersInRoles_AddUsersToRoles 'MyAppName', 'jack', 'CEO', 8
EXEC aspnet_UsersInRoles_AddUsersToRoles 'MyAppName', 'jack', 'Admin', 8

Por tanto los Roles a diferencia de los usuarios deben de aplicarse directamente a los permisos del sitio y no a otro grupo de SharePoint.  En ocasiones hemos aplicado a grupos de SharePoint y SharePoint no logra descubrir los permisos del usuario, en cambio por el otro lado si ha funcionado.


SharePoint4Fun!,


Juan Manuel Herrera Ocheita

jueves, 8 de enero de 2015

Nuevo hallazgo sobre como evitar la autenticación cuando se esta desplegando contenido de un App en SharePoint 2013

 

Luego que a realizado el procedimiento para registrar el nombre para las Apps en el DNS y también las del portal, pueda con que se tope que aún le pide las credenciales del usuario a pesar de que esta en una red interna o Intranet.  Si esto le sucede pueda que el problema sea el permiso que tiene el usuario.

Recientemente nos hemos percatado que el permiso mínimo que debe de tener un usuario en SharePoint para que no le solicite credenciales es Read y No Restricted Read.  Así valide eso por favor.  Algo que debe de tomar en cuenta es que SharePoint valida siempre sobre el nivel de permisos mayor que tenga el usuario esto para evitar conflictos en los permisos que puedan ser otorgados a los usuarios a través de los diferentes grupos y objetos de SharePoint (Sitios, Bibliotecas, Listas y elementos)

NOTA: Si usted esta teniendo este problema en una IOS su problema pueda derivarse a que el navegador de SAFARI no tiene las opciones de autenticación que si dispone IE por lo que una alternativa sería utilizar el Firewall de su organización para que guarde las credenciales del usuario cada vez que utilice el navegador Safari.  Ver más información aquí: http://sharepoint.stackexchange.com/questions/38086/sharepoint-repeatedly-prompting-ipad-users-for-credentials

Procedimiento para configurar Internet Explorer

How to hide the message "Only secure content is displayed":

1. In IE 10, go to Tools (alt+x) + Internet Options.

2. Go to the “Security TAB”

3. Select “Local Intranet”

4. Add to this zone the next domains:

a. Microsoftonline.com

b. Sharepoint.com

c. Yahooapis.com

5. Click on “Close” + “Apply”

6. Go to “Custom Level”:

7. Click on “enable” under the section “Display Mixed Content”:

8. Close the IE 10 completely, and re – open it (this is only required the first time, after applying the procedure).

9. Done.

Script en PowerShell para actualizar correo y puesto del perfil de usuario

Con la tendencia mundial de migración hacia la nube y en especial a Office 365, la migración de dominios que estén listos para Office 365 es uno de los caminos a seguir, pero en este proceso de migración pueden salir las cosas mal, por ello he escrito un Script en PowerShell para que actualice la propiedad de WorkEmail y Title (o sea Puesto) en el servicio de Perfiles de Usuario, basado en un archivo CSV con el objetivo de corregir algún error que se haya efectuado o bien porque no se han migrado aún los correos al nuevo dominio pero es necesario que sigan funcionando las alertas de SharePoint con la cuenta de correo anterior… Bueno y lo del puesto no sería necesario si se sincroniza, pero si se desea hacer una rápida actualización de un puñado de usuarios de esta propiedad sin necesidad de sincronizar todos los usuarios, es una solución práctica.

Como el Script se basa en un archivo CSV vamos a describir el formato de este archivo.

Formato del Archivo CSV

El formato CSV es un archivo de texto que tiene en su primera línea contiene el nombre de cada columna como parte del encabezado y se separa por una coma. Luego cada línea siguiente representa una fila y se separa igualmente por comas

Los nombres de las columnas del archivo CSV deben de tener por lo menos las siguientes:

NewAccount: Es la cuenta de usuario. Ejemplo: DOMINIO\NOMBRE_USUARIO

Title: El Puesto del usuario. Ejemplo: NOMBRE DEL PUESTO

Email: EL correo del usuario. Ejemplo: nombre_usuario@dominio.com

Un ejemplo del contenido de un archivo es el siguiente

NewAccount,Title,Email

DOMINIO\NOMBRE_USUARIO,Nombre del Puesto,nombre_usuario@dominio.com

El Script

 

#Primera línea de archivo UpdateUPAProperties.ps1

#Primero solicitaremos dos parámetros; $archivoEntrada = Que es la ruta de la ubicación del archivo csv y $misitioUrl que la URL de My Site. 

param (
    [string]$archivoEntrada , [string]$miSitioUrl
)

#Valida si fue ingresado el parámetro $archivoEntrada, sino le asigna un valor predeterminado para pruebas
if ($archivoEntrada -eq $null -or $archivoEntrada -eq "")
{
    $archivoEntrada = "E:\Infoware\Scripts\PruebaActualizaPropiedadesPerfilUsuario.csv"

    Write-Host "No ha recibido parametro archivoEntrada"
}

#Valida si fue ingresado el parámetro $miSitioUrl sino le asigna uno predeterminado
if ($miSitioUrl -eq $null -or $miSitioUrl -eq ""){
    $miSitioUrl = http://misitio.dominio.com
}

#Se Cargan las librerias de SharePoint para ejecutar la actualización de los perfiles de usuario

if((Get-PSSnapin | Where {$_.Name -eq "Microsoft.SharePoint.PowerShell"}) -eq $null) {
    Add-PSSnapin Microsoft.SharePoint.PowerShell;
}
[reflection.assembly]::Loadwithpartialname("Microsoft.Office.Server.Search") | out-null
[reflection.assembly]::Loadwithpartialname("Microsoft.Office.Server") | out-null

#Se Carga en memoria el Administrador de Perfiles de Usuario para ello es necesario la url que solicitamos en el parámetro e instanciar en memoria la colección de sitios y el sitio principal de MySite.
$site=Get-SPSite $miSitioUrl
$web=$site.RootWeb
$serverContext=[Microsoft.Office.Server.ServerContext]::GetContext($site)
$upm=New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($serverContext)


# Ahora cargaremos en memoria como una tabla el archivo CSV
$FileExists = (Test-Path $archivoEntrada -PathType Leaf)
if ($FileExists) {
   "Loading $archivoEntrada for processing..."
   $listadoUsuarios = Import-CSV $archivoEntrada
} else {
   "$archivoEntrada not found - stopping import!"
   exit
}

#El objetivo de esta función es actualizar el valor de la propiedad del perfil de usuario en cuestión

function set-SPProfileProperty([string]$propertyName, [string]$val, $up)
{

        #Validamos que no venga el perfil de usuario nulo
         if($up -ne $null)
        {

            #Obtenemos la propiedad por su nombre
            $property = $up.Properties.GetPropertyByName($propertyName)

     #Validamos que no si hayamos obtenido la propiedad


            if (-not [System.String]::IsNullOrEmpty($property))
            {
                $up[$propertyName].value = $val;
                $up.Commit();
                write-host "Actualizo la propiedad " $propertyName " con el valor" $val -ForegroundColor yellow
            }
        }
 
    Write-Host "Done" -foregroundcolor green
}

#Recorremos la tabla en memoria del archivo CSV

foreach ($row in $listadoUsuarios)
{
   $loginName = $row.NewAccount

   #Validamos que obtuvimos la columna NewAccount que trae la cuenta del usuario
   if( $loginName)
   {
        #validamos que el usuario exista en los perfiles de usuario
        if($upm.UserExists($loginName)){

            #Obtenemos el Perfil del Usuario
            $up = $upm.GetUserProfile($loginName);

            #Validamos que hayamos obtenido el perfil del usuario
            if($up) {
                $Puesto = $row.Title
                $Correo = $row.email       

                    #Si la columna Title trae valor invocamos la función para que modifique la propiedad en UPA
                    if($Puesto) {
                        set-SPProfileProperty -propertyName "Title" -val $Puesto -up $up
                
                    }

                   #Si la columna Corre trae valor invocamos la función para que modifique la propiedad en UPA

                    if($Correo) {
                        set-SPProfileProperty -propertyName "WorkEmail" -val $Correo -up $up
                    }
            }    
        }else
        {
            Write-Host "Usuario no existe " $loginName -ForegroundColor Red
        }
   }
}


Write-Host "End of file"
# Fin del archivo ps1

Procedimiento de Ejecución

Para ejecutar el Script puede utilizar PowerShell de Windows 3.0 o bien la consola de administración de SharePoint 2013.  Abajo una imagen que muestra como ejecutar el Script desde una ubicación predeterminada.

image

Bueno amigos espero les sirva el Scrip como lo hizo conmigo.

Hasta la próxima!… SharePoint4Fun!,

Juan Manuel Herrera Ocheita