miércoles, 31 de diciembre de 2014

Script para migrar Usuarios de cubos de dominio para una implementación de Inteligencia de Negocios en SharePoint

 

Introducción

En la edición Enterprise de SharePoint 2013 tenemos herramientas de inteligencia de negocios disponibles para exponer o desplegar la información de los cubos multidimensionales o tabulares en tableros de control mostrando indicadores de rendimiento o KPI´S, reportes, gráficos de todo tipo.  En la versión 2013 de SharePoint todas las herramientas de Excel como PowerPivot, PowerView, PowerQuery y otras más están disponibles para ser desplegada en un navegador o browser como lo es Internet Explorer, Chrome y Safari.   Típicamente cuando se implementa una solución así si implementa también Kerberos que es un protocolo de autenticación basado en reclamos o claims, donde hace posible que la identidad del usuario que se autentica en el portal de SharePoint no pierda su identidad sino que esta pueda ser pasada a otros servicios y servidores como lo es el Servidor de base de datos SQL Server y uno de sus servicios Analysis Services que nos sirve para procesar y construir los cubos multidimensionales y tabulares también.  Entonces cuando migramos los usuarios de dominio estos usuarios que están asignados a los roles de los cubos para mostrar solo aquellas dimensiones y medidas deseas es necesario adicionarlos a estos roles de los cubos que están disponibles y consumiéndose a través de Excel, SharePoint y Reporting Services, entre otros.   Por ello realizaremos un script en PowerShell para adicionar los usuarios del dominio anterior que se hayan migrado al dominio nuevo.

 

NOTA: En otro artículo veremos como migrar los permisos dentro de SharePoint de los usuarios del dominio anterior al actual, pero este no es el objetivo del artículo sino enfocarnos en los usuarios asignados a los roles de los cubos de Microsoft SQL Server Analysis Services o SSAS.

Objetivo

El siguiente script adiciona basado en un archivo CSV los usuarios a los roles de un cubo en específico. Para ejecutar el script ese necesario ejecutar PowerShell en modo administrador y pasar como parámetro la ruta del archivo CSV y el servidor y el nombre de la instancia de Analysis Services donde se encuentra el cubo.

 

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:

o BASE DE DATOS

o ROL

o USUARIO

El usuario debe de estar en el siguiente formato: DOMINIO\USUARIO, se reemplazara el dominio ANTERIOR por el nuevo DOMINIO. 

Ejemplo:

BASE DE DATOS,ROL, USUARIO

ZZ SIB PRUEBAS DOMINIO,Rol Analista,DOMINIO_ANTERIOR\nombre_usuario1

ZZ SIB PRUEBAS DOMINIO,Rol Analista,DOMINIO_ANTERIOR\nombre_usuario2

NOTA: Si el archivo CSV contiene más columnas de las esperadas esto no importa, lo importante es que existan las columnas que esta esperando el script.

EL SCRIPT

#definimos los parametros que recibirá el archivio de extensión ps1 que contendrá el siguiente código

param (
    [string]$archivoEntrada , [string] $servidorBaseDatos
)
 
if ($archivoEntrada -eq $null)
{
    $archivoEntrada = "F:\work\migracion-dominio\PruebasCubos3.csv"
    Write-Host "No ha recibido parametro archivoEntrada"
    #break
}
if ($servidorBaseDatos -eq $null){
    $servidorBaseDatos = "DELLLATITUDE8\TESTING"
    Write-Host "No ha recibido parametro servidorBaseDatosEinstanciaSQL"
    #break

}

# El siguiente comando solo debe de ejecutarse una primera vez para habilitar en la computadora la ejecución de script de forma remota
#Set-ExecutionPolicy RemoteSigned
# Esto se debe ejecutar cada vez que ejecute el script en powershell
#Import-Module sqlps -DisableNameChecking

$archivo = Import-Csv $archivoEntrada

[System.reflection.Assembly]::LoadWithPartialName("Microsoft.AnalysisServices")
$svr = new-Object Microsoft.AnalysisServices.Server


#AQUI VA LA MAGIA HACE UNA CONEXION AL SERVIDOR Y A LA INSTACIA NO PREDETERMINADA SINO NOMBRADA DE SSAS
$svr.Connect($servidorBaseDatos)

#Vamos a recorrer cada línea del archivo para adicionar dichos usuarios en los cubos y roles indicados en el archivo

ForEach ($item in $archivo){

    $usuario= $item.USUARIO   
    $usuarioNuevo=$usuario

    # VAMOS A REEMPLAZAR EL VALOR DE LA COLUMNA USUARIO LA PARTE DEL DOMINIO ANTERIOR POR LA ACTUAL LA CUAL SERA ADICIONADA EN EL ROL
    $usuarioNuevo=$usuario -replace "DOMINIO_ANTERIOR" , "DOMINIO_ACTUAL"   
    $basedatos = $item."BASE DE DATOS"
    $role = $item.Rol

        # VALIDAMOS QUE CADA COLUMNA REQUERIDA NO VENGA NULA O VACIA
        if($usuarioNuevo -ne $null -and $basedatos -ne $null -and $role -ne $null)
        {      

        #RECORREMOS LAS BASES DE DATOS DISPONIBLES EN LA CONEXION HACIA EL SERVIDOR DE SSAS QUE HICIMOS ARRIBA
        foreach ($db in $svr.Databases)
        {                       

            # COMPARAMOS EL NOMBRE DE LA BASE DE DATOS  DEL SERVIDOR CON LA DEL ARCHIVO
            If ($db.Name.ToLower() -eq $basedatos.ToLower())
                {

                # RECORREMOS TODOS LOS ROLES PARA COMPARARLOS CON LOS DEL ARCHIVIO
                foreach ($roles in $db.Roles)
                  {                   

                 # COMPARAMOS EL NOMBRE DEL ROL DE LA BASE DE DATOS  DEL SERVIDOR CON LA DEL ARCHIVO

                    if( $roles.Name.ToLower() -eq $role.ToLower())
                    {
                        $usuarioExiste = $false

                        # RECORREMOS CADA MIEMBRO DENTRO DEL ROL

                        foreach ($member in $roles.Members)
                                {                           

                                   # COMPARAMOS EL NOMBRE DEL USUARIO DEL ROL CON EL DEL ARCHIVO
                                    if ($member.Name.ToLower() -eq $usuarioNuevo.ToLower())
                                    {

                                           #ACTUALIZAMOS LA VARIABLE $usuarioExiste que luego nos servirá para realizar la actualización o no del usuario dentro del rol
                                            $usuarioExiste=$true
                                    }                           
                                }
                        if( $usuarioExiste -eq $true ){

                            # SI EL USUARIO EXISTE DESPLEGAREMOS UN MENSAJE EN LA CONSOLA QUE YA EXISTE
                            "Usuario "+ $usuarioNuevo +" ya existe"
                        }
                        else{

                            # SINO EXISTE EL USUARIO ENTONCES ADICIONAMOS EL USUARIO AL ROL
                            $roles.Name
                            $roles.Members.Add($usuarioNuevo)
                            $roles.Update()

                            # SI le da un error el función Update() valide cada usuario de la lista  ya que en ocasiones da error un usuario y este de replica en el resto no importando si esta bien el resto de usuarios debe de validar que el usuario en le nuevo dominio exista esto puede hacerlo intentando dar permisos a una carpeta en el servidor con el usuario del nuevo dominio.


                            "Usuario "+$usuarioNuevo+" agregado al Rol "+$roles.Name
                        }
                    }
                }
            }
        }
        }
}

 

Procedimiento

1. Levantar una sesión remota al servidor NOMBRE_SERVIDOR (Puede ejecutar el mstsc y d ebe tener credenciales para ingresar de modo remoto)

2. Ejecutar PowerShell como administrador en el Servidor de SQL Server 2012

3. Posicionarse en la carpeta d:\scripts

4. Ejecutar el script addUsersToRole.ps1 pasándole como parámetro el archivo donde se encuentran los usuarios a agregar script y el servidor y la instancia de Analysis Services donde se encuentran los cubos:

5. .\AddUsrsToRole.ps1 –archivoEntrada “\.Pruebas con cubos solo cubo de prueba.csv” –servidorBaseDatos SERVIDOR\NOMBRE_INSTANCIA_NO_DEFAULT

 

Bueno amigos, eso es todo por hoy en este artículo vimos como adicionar usuarios a los roles de cubos que son expuestos en SharePoint 2013 en un servidor de Analysis Services que tiene una instancia nombrada y no la predeterminada basado en un archivo separado por comas o CSV que contiene la información de la base de datos, el cubo, el rol y el usuario del dominio anterior que se adicionará como el nuevo.

SharePoint4Fun!,

Juan Manuel Herrera Ocheita

martes, 30 de diciembre de 2014

Error al asignar cuentas a la alertas de SharePoint en una migración de dominios

Cuando se están migrando usuarios de dominio pueda ser que no se migren de una vez sus buzones y esto implica que las alertas de SharePoint dejan de funcionar porque no esta asociado a una cuenta de correo la cuenta del nuevo dominio.  Las direcciones de correo en SharePoint Server son tomadas de los Perfiles de Usuario.  Este servicio tiene mapeado a través de propiedades que muchas de ellas apuntan a campos del Directorio Activo.

El campo del Directorio Activo que mapea la propiedad de Correo Electrónico d el servicio de Perfiles de Usuario es ProxyAddresses y esta es llenada cuando una cuenta de dominio tiene buzón de correo de Exchange. 

image

Entonces cuando se migra un usuario de dominio sin el buzón esta esta vacía que podemos hacer en el ínterin.  Bueno podemos utilizar el campo del Directorio Activo Mail y mapear esta en las propiedad del Perfil de Usuario. 

 

El procedimiento

Para que podamos realizar este procedimiento y mapear la propiedad del nuevo dominio es necesario crear una Conexión de Sincronización en el servicio de Perfiles de Usuario.  Como este tema no es el objetivo del artículo los dejo con la documentación de Technet para que la realicen:

http://technet.microsoft.com/es-es/library/ee721049(v=office.15).aspx#Phase2

Para mapear este nuevo campo del Directorio Activo en el Servicio del Perfil de Usuario, es necesario editar la propiedad del Perfil de Usuario, para ello seleccionamos dentro del Servicio la Opción “Administrar propiedades de usuario”.

image

Luego seleccionamos la opción Editar de la Propiedad Correo Electrónico del trabajo  que se encuentra en la sección Información del contacto.

image

Dentro de la edición en la parte de abajo encontraremos el mapeo hacia el Directorio Activo

image

En la opción Agregar nueva asignación seleccionaremos el nuevo dominio en el dropdown list Conexión de datos de origen. Y el Atributo buscaremos el nombre “Email”.  En el campo Dirección deberemos de seleccionar la opción Importar y por último presionamos el botón Agregar.

image

El resultado deberemos verlo un poco arriba en la sección Asignación de propiedades para sincronización como se muestra en la imagen de abajo.

image

Por último presionamos el botón Aceptar y listo.  Podemos sincronizar los perfiles y revisar si efectivamente tomo el correo electrónico del campo Mail del Directorio Activo.

Con esta configuración las cuentas que no están migradas aún utilizaran el campo proxyAddresses y para las cuentas del nuevo dominio se utilizarán el campo mail del nuevo dominio.

Hasta la próxima amigos SharePoint4Fun!,

Juan Manuel Herrera Ocheita

sábado, 27 de diciembre de 2014

Moviendo una granja de SharePoint a una zona desmilitarizada o DMZ

 

Para comprender a lo que nos estamos metiendo vamos a definir primero que es una DMZ (Extracto de Wikipedia http://es.wikipedia.org/wiki/Zona_desmilitarizada_(inform%C3%A1tica))

DMZ

En seguridad informática, una zona desmilitarizada (conocida también como DMZ, sigla en inglés de demilitarized zone) ored perimetral es una red local que se ubica entre la red interna de una organización y una red externa, generalmente enInternet. El objetivo de una DMZ es que las conexiones desde la red interna y la externa a la DMZ estén permitidas, mientrasque en general las conexiones desde la DMZ solo se pParaermitan a la red externa -- los equipos (hosts) en la DMZ no pueden conectar con la red interna. Esto permite que los equipos (hosts) de la DMZ puedan dar servicios a la red externa a la vez que protegen la red interna en el caso de que intrusos comprometan la seguridad de los equipos (host) situados en la zona desmilitarizada. Para cualquiera de la red externa que quiera conectarse ilegalmente a la red interna, la zona desmilitarizada se convierte en un callejón sin salida.

La DMZ se usa habitualmente para ubicar servidores que es necesario que sean accedidos desde fuera, como servidores de correo electrónico, Web y DNS. Y es precisamente estos servicios alojados en estos servidores los únicos que pueden establecer tráfico de datos entre el DMZ y la red interna, por ejemplo, una conexión de datos entre el servidor web y una base de datos protegida situada en la red interna.

NAT (Network address translation)

Para aislar los equipos dentro de la DMZ de la red interna, se implementa una NAT con el objeto de traducir las direcciones públicas en internas.

Este mecanismo se implementa en un dispositivo de enrutamiento que utiliza tablas de traducción “estado” que mapea las direcciones ocultas en una sola dirección  IP que expone en Internet aparentando que fueron originados del dispositivo de enrutamiento.En la ruta de comunicación inversa, el Router mapea las respuestas de regreso a las direcciones IP originadas utilizando las reglas “Estado” almacenadas en las tablas de traducción.

Por ende si se desea acceder los servidores desde internet se utilizarán las IP publicas o externas si se desea acceder desde la red interna se utilizan las IP de la red interna.

 

CONFIGURACION

Debido a que las IPs son modificadas y se bloquean muchos puertos dentro de la DMZ es necesario revisar que estén abiertos:

Deberemos revisar el archivo host también para validar que no hayan registro desactualizados apuntando al las ips anteriores.

Podemos utilizar las siguientes utilerías:

1) ipconfig /flushdns  (Esto comando elimina el cache del DNS)

2) ping nuevas direcciones

3) telnet dirección ip : puerto  (Este es necesario instalarlo de las características o features de Windows)

Los puertos que deberán estar abiertos son los siguientes:

Protocol

Port

Usage

Comment

TCP

80

http

Client to SharePoint web server traffic
(SharePoint – Office Web Apps communication)

TCP

443

https/ssl

Encrypted client to SharePoint web server traffic
(Encrypted SharePoint – Office Web Apps communication)

TCP

1433

SQL Server default communication port.

May be configured to use custom port for increased security

UDP

1434

SQL Server default port used to establish connection

May be configured to use custom port for increased security

TCP

445

SQL Server using named pipes

When SQL Server is configured to listen for incoming client connections by using named pipes over a NetBIOS session, SQL Server communicates over TCP port 445

TCP

25

SMTP for e-mail integration

Cannot be configured

TCP

16500-16519

Ports used by the search index component

Intra-farm only
Inbound rule Added to Windows firewall by SharePoint

TCP

22233-22236

Ports required for the AppFabric Caching Service

Distributed Cache…

TCP

808

Windows Communication Foundation communication

WCF

TCP

32843

Communication between Web servers and service applications

http (default) To use custom port, see references section
Inbound rule Added to Windows firewall by SharePoint

TCP

32844

Communication between Web servers and service applications

https
Inbound rule Added to Windows firewall by SharePoint

TCP

32845

net.tcp binding: TCP 32845 (only if a third party has implemented this option for a service application)

Custom Service Applications
Inbound rule Added to Windows firewall by SharePoint

TCP

32846

Microsoft SharePoint Foundation User Code Service (for sandbox solutions)

Inbound on all Web Servers
Inbound rule Added to Windows firewall by SharePoint
Outbound on all Web and App servers with service enabled.

TCP

5725

User Profile Synchronization Service(FIM)

Synchronizing profiles between SharePoint 2013 and Active Directory Domain Services (AD DS) on the server that runs the Forefront Identity Management agent

TCP + UDP

389

User Profile Synchronization Service(FIM)

LDAP Service

TCP + UDP

88

User Profile Synchronization Service(FIM)

Kerberos

TCP + UDP

53

User Profile Synchronization Service(FIM)

DNS

UDP

464

User Profile Service(FIM)

Kerberos change password

TCP

809

Office Web Apps

Intra-farm Office Web Apps communication.

Referencia Original de Microsoft: http://technet.microsoft.com/en-us/library/cc262849.aspx

NOTA:  En ocasiones SharePoint no despliega las páginas adecuadamente y lo que se ha tenido que hacer es ejecutar el asistente de Configuración de SharePoint.

SharePoint4Fun!,

Juan Manuel Herrera Ocheita

martes, 16 de diciembre de 2014

Como configurar la topología del Servicio de Búsqueda en varios Servidores

Cuando contamos con más de 2 servidores para la granja de SharePoint Server 2013 podemos configurar un servidor para que se ocupe de algunos o todos los procesos del servicio de búsqueda y así distribuir la carga de trabajo entre los servidores de la granja de SharePoint.

Porque el servicio de búsqueda porque este en mi experiencia y en la documentación de Microsoft consume muchos recursos vea el siguiente cuadro.

Service Application

Web server CPU

Web server RAM

Application server CPU

Application server RAM

SQL Server CPU

SQL Server IOPS

SQL Server storage

SharePoint Foundation Service

XXX

XXX

 

 

XX

XXX

XXX

SharePoint Search Service

XXX

XXX

XXX

XXX

XXX

XXX

XXX

InfoPath Forms Service

XX

XX

XX

XX

X

X

X

Workflow capabilities *

XXX

XXX

 

 

 

 

 

Timer Service

XX

XX

XX

XX

 

 

 

X – Indica un costo insignificante del recurso. El servicio puede compartir el recurso con otros servicios.

XX – Indica un costo medio del recurso. El Servicio podría compartir el recurso con otros servicios con un impacto mínimo.

XXX – Indica un costo alto del recurso. El Servicio debería no compartir el recurso con otros servicios.

SharePoint Foundation Service   El servicio central de SharePoint para la colaboración de contenido. En las grandes implementaciones de SharePoint Server 2010, se recomienda asignar servidores Web redundantes basados ​​en carga prevista del tráfico, dimensionar adecuadamente las computadoras basadas en SQL Server que dan servicio a las bases de datos de contenido y asignar adecuadamente el almacenamiento basado en el tamaño de la granja.

SharePoint Search Service Application   La aplicación de servicio compartida que proporciona capacidades de indización y consulta. En general, este es un servicio relativamente intensiva de recursos, que puede escalar para servir a grandes despliegues de contenido. En 2010 implementaciones donde la búsqueda empresarial es muy importante gran SharePoint Server, le recomendamos que utilice una "granja de servicio" independiente para hospedar aplicaciones de servicio de búsqueda, con los recursos de base de datos dedicada, use múltiples servidores de aplicaciones de las funciones específicas de búsqueda de servicio (crawl o consulta), y servidores Web dedicados objetivo de las granjas de contenido para asegurar el rendimiento aceptable para el rastreo y la consulta.

Dentro de la arquitectura del Servicio de Búsqueda de SharePoint 2013 podemos elegir varias configuraciones dependiendo de nuestra necesidades.   Para ello debemos de conocer los componentes del Servicio.  La imagen a continuación nos ayudará a descubrirlo:

image

Podemos indicar que este servicio se compone de 5 componentes principales:

1) Componente de Indagación / Crawling

Este componente es responsable de indagar el contenido.  Utiliza conectores para obtener la información de las fuentes de contenido, pero no procesa ningún texto o documentos.  El resultado de la indagación es el contenido y su metadatos. Y son pasados el siguiente componente de Procesamiento de Contenido. En otras palabras este proceso prácticamente hace un inventario burdo sin procesar del contenido.

2) Componente de Procesamiento de Contenido / Content Processing

Este procesa los elementos indagados y alimenta al Componente de Índice.  Este procesa el contenido según los manejadores de formatos.  Incluye lo siguientes formatos: HTML, DOCX, PPTX, TXT, Image, XML and PDF. En 2013 aún los manejadores de formatos IFilters son soportados (el ifilter para PDF ya no es necesario instalarlo ya que esta versión ya lo incluye).  Este ordena y procesa el inventario hecho por el indagador.

3) Componente de Índice / Index

Este componente es utilizado para los procesos de alimentación y consulta.  Por un lado recibe los elementos procesados del componente de Procesamiento de Contenido para luego persistirlos en el índice. Por el otro lado recibe las consultas del componente de Procesamiento de Consulta y devuelve el conjunto de resultados solicitados. También es responsable de la ubicación del contenido indizado, según la topología se haya definido en el componente de Administración. En otras palabras este almacena el índice del contenido que se utilizará para las consultas.

4) Componente de Procesamiento de Consulta / Query Processing

Este recibe una consulta de búsqueda del Front-End y analiza y procesa la consulta.  La consulta procesada es enviada al componente de Índice. El Índice retorna el conjunto de resultados el cual procesa antes de ser devueltos al Front-End.  En otras palabras este traduce la consulta hecha por el usuario al índice y traduce los traduce de vuelta resultados retornados por el índice.

5) Componente de Procesamiento Analítico

Este rastrea y analiza los elementos indagados y como los usuarios utilizan los resultados de búsqueda, con el objetivo de mejorar de forma continua la relevancia de los resultados de la búsqueda.  Los resultados de este componente son devueltos  al componente de Procesamiento de Contenido para ser incluido en el Índice. En otras palabras este perfecciona y prioriza el ordenamiento del contenido que será almacenado en el índice.

6) Componente de Administración

Este componente es responsable por la topología del servicio y su configuración.  Este coordina los componentes de Procesamiento de Contenido, Consulta, Índice y Analítico.  En otras palabras este coordina los procesamientos de ordenamiento, priorización, índice y Consulta.

La Configuración

Utilizáremos PowerShell (Es necesario cargar en memoria las librerias de SharePoint con el comando Add-PSSnapin “Microsoft.SharePoint.PowerShell”) o el Management Shell para SharePoint (este ya incluye las librerías precargadas de SharePoint) para modificar la configuración predeterminada del servicio de búsqueda.  Es una tarea muy fácil luego de entender como funciona cada componente y la configuración que se desea.

En este escenario vamos a mover los componentes de mayor carga para los servidores el de procesamiento de Contenido, el Analítico e indagación de contenido al servidor identificado como CRAWLING-SERVER y el resto lo dejaremos en el servidor FRONT-END-SERVER que son el de procesamiento de consulta, índice y administración.

image

Primero deberemos identificar los servidores que vamos a utilizar para modificar la topología del servicio de Búsqueda.  Para ello es necesario tener instalado SharePoint en ambos servidores y que pertenezcan a la misma granja, una vez que hayamos completado con estos requerimientos.   Abrimos como administrador la ventana de Management Shell para SharePoint y ejecutamos las siguientes líneas:

$hostA = Get-SPEnterpriseSearchServiceInstance -Identity "FRONT-END-SERVER"

$hostB = Get-SPEnterpriseSearchServiceInstance -Identity "CRAWLING-SERVER"

Start-SPEnterpriseSearchServiceInstance -Identity $hostA
Start-SPEnterpriseSearchServiceInstance -Identity $hostB

#Luego instanceamos en memoria el servicio y la topología que deseamos configurar

$ssa = Get-SPEnterpriseSearchServiceApplication

$newTopology = New-SPEnterpriseSearchTopology -SearchApplication $ssa

#Luego debemos indicar en que servidor estará cada componente

New-SPEnterpriseSearchAdminComponent -SearchTopology $newTopology -SearchServiceInstance $hostA
New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $hostA
New-SPEnterpriseSearchIndexComponent -SearchTopology $newTopology -SearchServiceInstance $hostA -IndexPartition 0
New-SPEnterpriseSearchCrawlComponent -SearchTopology $newTopology -SearchServiceInstance $hostB
New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $hostB
New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $hostB

#Y por ultimo persistir esta configuración

Set-SPEnterpriseSearchTopology -Identity $newTopology

 

Problemas:

Si en caso le despliega este error:

##Set-SPEnterpriseSearchTopology : Could not connect to the HostController service on server Topology Activation could not be started.

Intente con la siguiente línea de comando

Start-SPEnterpriseSearchQueryAndSiteSettingsServiceInstance -Identity "SERVERNAME"

En este artículo explicamos de forma muy breve los componentes de la arquitectura del servicio de búsqueda y luego como podemos distribuir estos componentes en diferentes servidores, la cual es muy sencilla gracias a PowerShell y el modelo de objetos de SharePoint que nos permite administrar estos componentes como objetos lógicos en memoria.


Eso es todo amigos hasta la próxima.


SharePoint4Fun!,


Juan Manuel Herrera Ocheita

Arquitectura Recomendada para una granja pequeña de SharePoint 2013 para las exigencias actuales

SharePoint puede ser instalado en una sola caja (refiriéndome a un servidor físico) o Servidor Virtual, pero esta configuración esta diseñado solo para demostraciones o pruebas rápidas de la plataforma.  Hoy en día con Office 365 que incluye SharePoint Online se aprecia mejor una demostración desde la nube que preparar una instalación de la plataforma.

El siguiente nivel es utilizar dos servidores físicos, virtuales o mixtos (uno físico y otro virtual) que es la configuración  mínima de una granja de SharePoint.  Un Servidor de base de datos y otro Servidor para los bits de SharePoint donde cubra los roles de Front-End y Aplicación.

Pero hoy en día hablamos de grandes volúmenes de información, diferentes orígenes de datos, los usuarios exigen un nivel de actualización de índices para la búsqueda de horas o minutos con lo cual debemos de pensar que el servicio de búsqueda debería de estar dedicado en un servidor por aparte.  Luego que los usuarios quieren editar sus documentos en cualquier parte y colaborar en la edición por lo que es necesario proveerles de edición Web y eso lo hacemos con un servidor con ese rol Office Web Apps.  Y por ultimo es necesario cumplir con las políticas de seguridad que nos obligan a la separación de responsabilidades o concerns, por lo que debemos de pensar en un servidor para la administración central de SharePoint o Central Administration por separado ejecutando las tareas de mantenimiento típicas de SharePoint (Limpieza, validación de estado de salud, ejecución de flujos de trabajo y trabajos de actualización de las preferencias y actividades del usuario dentro del portal).

La propuesta de la arquitectura recomendada sería la siguiente:

image

Estamos hablando de 4 servidores esta aún es considerada una granja pequeña que no cuenta con redundancia, pero que tiene distribuida la carga y los roles bien definidos.

BackEnd

De abajo hacia arriba de izquierda a derecha, tenemos el Back-End que es el servidor de base de datos el aplicativo a utilizar aquí es SQL Server 2012 Business Intelligence para la edición Enterprise de SharePoint.  Si fuese para la edición Standard de SharePoint sería la versión Standard de SQL Server.  Aquí se almacenarán las bases de datos de SharePoint, todas; las de configuración, servicios y contenido.  Para la edición Enterprise de SharePoint es necesario instalar la edición BI o Enterprise de SQL Server en modo SharePoint Integrado debido a la implementación de PowerPivot especializada para SharePoint que hay dentro de las configuraciones de SQL Server Business Intelligence o Enterprise (Para más información puede consultar el siguiente enlace: http://msdn.microsoft.com/en-us/library/hh231671(v=sql.110).aspx). 

La configuración de estos servidores varia conforme a los objetivos y volumen de la información, pero para una granja pequeña de 1 TB de contenido la siguiente configuración me ha funcionado muy bien:

Procesador 4 núcleos

RAM 16-24 GB RAM

Discos: 1-150GB OS&Software, 2-2 TB BASES DE DATOS, 3-800 GB LOGS DE BASE DE DATOS (Los discos más rápidos disponibles)

Application Server

Este servidor de aplicación deberá ser el primero donde se instale los bits de SharePoint en este se instalará el Central Administration o Administración Central de SharePoint esto por temas de seguridad ya que el servidor que atiende las solicitudes de los usuarios el Front-End esta más expuesto que el de aplicación.  Según el diagrama de arriba se utilizará con el propósito de separar el servicio de búsqueda del resto de servicios de SharePoint o bien del Front-End.  Aquí hay una importante decisión que hacer, ya que podemos optar por tener todos los servicios estén en el servidor de aplicación y dejar el Front-End solo atendiendo las solicitudes de los usuarios o bien en el servidor de aplicación solo mantener el servicio de búsqueda en este servidor y el resto en el Front-End. El primer escenario estamos liberando el Front-End para darle prioridad a las solicitudes de los usuarios, esto permitirá atender a más usuarios de forma inmediata ya que este servidor solo esta definido para esta función y en el servidor de Aplicación esta la carga de todas los procesos internos del servidor.  En caso que falle el servidor de aplicación, ningún servicio más que el de navegar en el portal estará disponible.  En el segundo escenario donde solo el servicio de búsqueda esta configurado en este servidor entonces la carga esta compartida entre el Front-End y este servidor.  Aunque el servicio de búsqueda es uno de los servicios que más consume recursos especialmente procesador.  Si el servidor de aplicación se cae solo se verá afectado el servicio de búsqueda del portal el resto de servicios están hospedados en el Front-End.  En resumen en el primer escenario donde toda la carga la tienen el Servidor de Aplicación, permite una navegación rápida pero en caso de falla se pierden todos los servicios de SharePoint.  En el segundo escenario donde la carga principal que es el servicio de búsqueda esta en el servidor de Aplicación permite una descarga importante en el Front-End y si en caso falla solo se verá afectado el servicio de búsqueda.  En casos de alta disponibilidad o servicios críticos se puede colocar redundancia en este servicio.  Para más información sobre como configurar y administrar el servicio de búsqueda puede consultar el siguiente enlace: http://technet.microsoft.com/en-us/library/jj219705(v=office.15).aspx

La configuración de estos servidores varia conforme a los objetivos y volumen de la información, pero para una granja pequeña de 1 TB de contenido la siguiente configuración me ha funcionado muy bien:

Procesador 4 núcleos

RAM 12 GB RAM

Discos: 1-150GB OS&Software, 2-500 GB (Para almacenar el índice en el sistema de archivos del servicio de búsqueda)

Office Web Apps Server

Este servidor no requiere instalar los bits de SharePoint, ya que este servidor puede recibir solicitudes no solo de SharePoint, sino también de Exchange y Lync.  Para el caso de SharePoint este servidor puede instalarse de forma gratuita solo para la visualización de documentos de Office dentro del portal, sin necesidad de tener el producto de escritorio de Microsoft Office.  Por otro lado si ha adquirido las licencias de Office Professional Plus tiene derecho a instalar este producto en un servidor para la edición de documentos de Office desde el navegador esto reduce la carga operacional y el costo total de propiedad  que se requiere para editar los documentos de Microsoft Office.  Y así utilizar cualquier dispositivo móvil para visualizar y editar los documentos no importando si es iOS o Android, ya que el código que edita los documentos corre de lado del servidor y no del cliente, esto permite una gran movilidad.  Así que mejor aproveche esta funcionalidad apartando un servidor para este objetivo.  Para más información de como instalar OWA y configurarlo para SharePoint vea el siguiente enlace: http://technet.microsoft.com/en-us/library/ff431687(v=office.15).aspx

Front-End

Según la decisión que haya tomado para el servidor de aplicación aquí deberá instalar los bits de SharePoint (o sea la media, que requiere otra licencia de servidor en la misma edición con que instaló el servidor de aplicación). Este servidor al momento de ejecutarse el asistente de productos y tecnologías de SharePoint le preguntará si desea crear una nueva granja o conectarse a una existente allí deberá indicar que es a una existente indicando el servidor de base de datos, la base de datos de configuración de la granja (típicamente SharePoint_Config).  También le solicitará la frase de la granja que coloco al instalar el servidor de aplicación. 

La configuración de estos servidores varia conforme a los objetivos y volumen de la información, pero para una granja pequeña de 1 TB de contenido y alrededor de 3000 usuarios la siguiente configuración me ha funcionado muy bien:

Procesador 4 núcleos

RAM 16-24 GB RAM

Discos: 1-200GB OS&Software, 2-200 GB (Para almacenar los archivos .log y .usage)

Bueno amigos eso es todo por este artículo espero les sirva y puedan tomar en cuenta otros aspectos cuando decidan estimar el tamaño de su granja de SharePoint.

Hasta la próxima, SharePoint4Fun!

Juan Manuel Herrera Ocheita

miércoles, 12 de noviembre de 2014

Reconociendo otros dominios del directorio activo en SharePoint 2013, 2010 y 2007

El Problema

Cuando deseamos asignar permisos o tareas a usuarios de otros dominios no es posible encontrarlos en las ventanas de búsqueda de usuarios de SharePoint denominada PeoplePicker.  Qué debemos de configurar en SharePoint para que pueda realizar búsquedas en otros dominios a los predeterminados?.  Eso es lo que resolveremos en este artículo.

image

NOTA: Este artículo aplica a las versiones de 2007 a la 2013 de SharePoint tanto Services, Foundation y Server debido a que todavía se puede utilizar el comando stsadm.exe aunque en powershell esta disponible el equivalente es mucho mas sencillo utilizar el stsadm.exe.

Escenario

La granja de SharePoint esta en una Zona Desmilitarizada o DMZ y los usuarios de la intranet pertenecen a diferentes bosques o forest.  En total son 3 bosques del directorio Activo, el bosque predeterminado donde esta instalado la granja de SharePoint que denominaremos xyz.local y los otros bosques denominaremos como abc.com y fgh.local.  Como esta en una DMZ la mayoría de puertos están bloqueados entonces es necesario desbloquear los puertos que utiliza la implementación del directorio activo para su descubrimiento, el cual si es la implementación del AD predeterminado sería el puerto 389.  

Requisitos

Antes de realizar las pruebas  a través de la aplicación telnet deberemos asegurarnos que el dominios puedan resolverse desde el front-end de SharePoint ya sea por DNS o archivos host.  Para ello vamos a levantar una ventana de línea de comando y ejecutar el comando ping de la siguiente manera:

c:\>ping abc.com

c:\>ping fhg.local

Esto nos debería de responder con la ip de algún controlador de dominio que nos responda de estos dominios.

Para comprobar la comunicación en el servidor de front-end hacia estos bosques y puerto podemos realizar las siguientes pruebas por medio de la aplicación telnet.  Si la aplicación no esta disponible en el servidor puede habilitarse por medio de las características de Windows Server en la opción del Panel de control, Programas y Características.

Si ya tenemos la aplicación telnet habilitada podemos ejecutar las siguientes líneas de comando como administradores locales del servidor de front-end de SharePoint:

c:\>telnet xyz.local 389

c:\>telnet abc.com 389

c:\>telnet fgh.local 389

El resultado debería ser que la pantalla se borra y el prompt esta disponible para escribir, sino marcará un error indicando que el puerto no esta disponible o que esta cerrado.  Entonces deberá solicitarse que se abran estos para la comunicación entre dominios.

Si la implementación de los otros bosques incluyen SSL o kerberos consultar el siguiente artículo:

http://blogs.technet.com/b/wbaer/archive/2009/01/21/people-picker-port-protocol-requirements.aspx

Validaciones

Se deberá validar que estos bosques y/o dominios del directorio activo tenga relación de confianza ya sea full trust o completa o en una sola vía.   Si es una sola vía deberemos incluir las credenciales de una cuenta del dominio al que deseamos realizar la búsqueda del usuarios desde SharePoint. Si por el contrario es una relación de confianza completa o full trust entonces no es y no debemos de pasar las credenciales de usuario para que funcione.  Esto lo podemos hacer por medio de la consola administrativa Active Directory Domains and Trust.

http://technet.microsoft.com/en-us/library/cc753821.aspx

El proceso de habilitación de los otros dominios

Bueno ahora vamos a ejecutar la línea de comando stsadm.exe para ello debemos de abrir la consola de administración de SharePoint o bien dirigirnos a la siguiente ruta según la versión de SharePoint:

c:\program files\common files\microsoft shared\web server extensions\12\bin

c:\program files\common files\microsoft shared\web server extensions\14\bin

c:\program files\common files\microsoft shared\web server extensions\15\bin

12 para 2007, 14 para 2010 y 15 para 2013.

primero vamos asegurarnos que no hay ninguna ruta definida.  Para consultarla podemos ejecutar la siguiente línea de comando:

stsadm.exe –o getproperty -pn peoplepicker-searchadforests –url http://sharepoint-web-application:80

Para limpiar los valores que tenga y no sean los correctos podemos ejecutar la siguiente línea de comando

stsadm.exe –o setproperty -pn peoplepicker-searchadforests –url http://sharepoint-web-application:80 –pv “”

Ahora para registrar los bosques y dominios tanto el predeterminado como los otros deberemos ejecutar la siguiente línea de comando

stsadm.exe –o setproperty -pn peoplepicker-searchadforests –url http://sharepoint-web-application:80 –pv “forest:xyz.local;doamin:xyz.local;forest:abc.com;domain:abc.com;forest:fgh.local;domain:fgh.local”

Para relaciones de confianza de una sola vía deberemos incluir la cuenta domain admin o enterprise admin para que pueda realizar las búsquedas dentro de esos bosques.  Entonces el comando se transformaría en lo siguiente:

stsadm.exe –o setproperty -pn peoplepicker-searchadforests –url http://sharepoint-web-application:80 –pv “forest:xyz.local;doamin:xyz.local;forest:abc.com,xyz\domainadmin,password;domain:abc.com;forest:fgh.local,xyz\domainadmin,password;domain:fgh.local”

Va seperado por comas luego de definir el nombre del forest.

Y eso es todo.  En la red hay artículos que hacen referencia a una propiedad de SPSite llamada UserAccountDirectoryPath, esta bloquea más que corregir el problema asegurese que esta en blanco.  Esta es por colección de sitios y una aplicación Web puede tener “n” colecciones de sitios así que deberá ejectar el comando por cada colección de sitios de la siguiente forma, desde PowerShell de SharePoint:

Set-SPSite -Identity http://sharepoint-web-application -UserAccountDirectoryPath "”

Set-SPSite -Identity http://sharepoint-web-application\sites\rrhh -UserAccountDirectoryPath "”

Set-SPSite -Identity http://sharepoint-web-application\sites\IT -UserAccountDirectoryPath "”

Para validar si tiene algún valor puede ejecutar la siguientes líneas de comando vía powershell:

$site = Get-SPSite –Identity http://sharepoint-web-application

$site.UserAccountDirectoryPath

Este deberá devoler algún valor si lo tienen ingresado.

Los interesados en ejecutar este procedimiento en PowerShell ver el siguiente enlace:

http://xblogs.kompas-xnet.si/post/The-People-picker-and-domain-trusts.aspx

Bueno amigo con ello debería poder desde el peoplepiker o las opciones de Compartir o asignar permisos los usuarios de los otros dominios.  Esto no esta ligado con los perfiles de usuario que para ello deberá crearse una conexión para cada dominio, pero esto es otra historia para otro artículo.

SharePoint4Fun,

Juan Manuel Herrera Ocheita

domingo, 12 de octubre de 2014

Una breve introducción sobre la arquitectura de SharePoint Server

SharePoint desde su versión 2010 consta de 3 capas; Presentación (Front-End), Aplicación (Application Server) y Base de Datos (Back End). Los 3 roles son definidos de la siguiente manera:

SharePoint Server 2010 farm:Add a server

Base de Datos (Back End): Este es exclusivo para SQL Server y pueden constar de varios servidores de bases de datos aislados (donde almacenamos en cada servidor diferentes bases de datos de SharePoint, por ejemplo;configuración, servicios o contenido) o bien arreglos redundantes como Clustering o Mirroring para alta disponibilidad de este Rol.  Aquí no es necesario instalar los bits de SharePoint, solo SQL Server como aplicación central dentro del servidor.

Aplicación (Application Server): En este servidor se recomienda que este instalado el Central Administration.  Puede disponer de varios servidores aislados los cuales pueden ejecutar diferentes servicios. También puede existir redundancia de servicios (aunque no de todos) en caso sean críticos como la búsqueda, perfiles de usuario, entre otros.  Aquí se requiere tener instalado los bits de SharePoint, es decir requerimos una licencia de SharePoint Server.

Presentación (Front-End): Este servidor primordialmente este diseñado para hospedar las aplicaciones Web que los usuarios consumen al hacer la solicitud en el navegador.  Aquí la redundancia para balancear cargas o para tener alta disponibilidad es un escenario común en granjas de más de 4 servidores.  Aquí no se puede utilizar un servidor para hospedar una aplicación Web y en otro servidor otra, no esta así diseñado SharePoint.  Aquí se requiere tener instalado los bits de SharePoint, es decir requerimos una licencia de SharePoint Server.

Replica de los sitios Web del IIS:  Algo curioso es que cuando creamos la aplicación Web en el servidor Front-End desde el Central Administration o vía PowerShell, el sitio Web en el IIS es replicado en el servidor de aplicación donde esta hospedado el Central Administration, esto lo hace SharePoint para tener una replica del sitio Web creado en el IIS y pueda ser restablecido en otro servidor de Front-End de SharePoint.  Cuando instalamos alguna solución de granja o Farm Solution o componente que utilizará nuestra aplicaciones instaladas en SharePoint es necesario instalarlas en cada servidor de Front-End y Application Server dependiendo de la arquitectura de la solución.

El orden de Instalación:

Base de Datos (Back End): Ya que la configuración, servicios y contenido es almacenado en base de datos, el primer servidor que debemos instalar es el base de datos o Back-End.  Para ello necesitamos la media de SQL Server 2008 R2 con el SP1 como mínimo o superior para la edición Standard de SharePoint Server y para la edición Enterprise de SharePoint debe de ser SQL Server Business Intelligence 2012 o Enterprise. 

Recomendaciones importantes:  Si es una instalación existente de SQL Server deberá crearse una instancia Nueva para ocupar SharePoint y asignar recursos de memoria y procesador a esta para garantizar un nivel de rendimiento en SharePoint.   Recomiendo que si va a ser una instalación nueva se elija SQL Server 2012 Standard si es para las edición Standard de SharePoint Server.

Aplicación (Application Server): El Segundo servidor que debemos de instalar es el de aplicación para una granja de por lo menos 3 servidores.  Si solo son dos pues no aplica los roles de App-Server y Front-End están en uno mismo.   Este servidor es el que va dar a luz la granja de SharePoint en este crearemos la aplicación Web para el Central Administration. 

Luego de instalar los bits de SharePoint, nos preguntará el Asistente de Productos y Tecnologías de SharePoint si deseamos crear una granja nueva o conectarnos a una existente, con lo cual indicaremos que deseamos crear una nueva granja.  Nos solicitará el nombre de la base de datos con lo cual sugiero utilizar un alias de SQL por futuros cambios o restauraciones en caso de falla de servidor de base de datos y la cuenta que será la administradora de la granja de SharePoint denominada común mente como midominio\spfarm.  Luego solicitará el puerto donde lo crearemos sugiero un número fácil de recordar como 5 veces 5 es decir http://hostname:55555

image

Esto creará las primeras dos base de datos SharePoint_Config (donde se guarda la configuración de la granja) y Wss_Content_Admin[id único] (la cual es la base de datos de contenido de la aplicación Web que hospeda el Central Administration).  También nos solicitará la frase de contraseña de la granja esta es importante ya que para adicionar cualquier servidor es necesario esta contraseña.  Recomiendo sea la misma contraseña de la cuenta spfarm para no olvidar cual colocamos. 

Si nuestra granja contará con más de 3 servidores y la redundancia o la distribución de la carga va a ser en este rol, tendremos que instalar los bits de SharePoint en cada uno de los servidores adicionales (y si es una licencia de servidor adicional, lo que no tiene que volver a pagar es las CAL de usuario no importa cuantos servidores tenga una USER CAL es por usuario y no por servidor. 

Presentación (Front-End):

image

Para adicionar un servidor necesitamos instalar los bits de SharePoint y cuando se ejecute el asistente de Productos y Tecnologías de SharePoint, colocar que no es una nueva granja sino que nos vamos a conectar a una existente debemos de colocar el nombre del servidor de base de datos o el alias de SQL (para ello es necesario instalar sql serve express y crear el alias en el servidor que se desea conectar al de base de datos), seleccionamos la base de datos de configuración que muy seguramente es SharePoint_Config, la cuenta administradora de la granja (asumimos que sea midominio\spfarm) y la contraseña. 

Además nos solicitará la frase de contraseña de la granja de SharePoint.

image

Cómo se asignan los roles de Servidor:

En el siguiente enlace http://technet.microsoft.com/es-gt/library/cc261752(v=office.15).aspx hay una nota al final que podemos pasar desapercibidos en el cual indica que “El nuevo servidor no tiene ninguna funcionalidad real en la granja de servidores hasta que se configuran los servicios necesarios para obtener compatibilidad con el rol que ha planeado para el nuevo servidor. Para más información, vea Configuración de servicios y aplicaciones de servicio en SharePoint 2013.”  Esto claramente nos indica que hasta después de adicionar el servidor a la granja y crear el servicio o la aplicación web en el servidor por medio de línea de comando le asignamos el rol según la funcionalidad que le configuremos.

Para crear la aplicación Web explicitamente en el Front End podemos utilizar el siguiente script para ejecutar en PowerShell:

$farmAcct = "midominio\spapp"
$AliasName = "SPSQL"
$webAppName = "SharePoint – Portal "
$appPool = "SharePoint - Portal"
$Contentdatabase = "WSS_Content_Portal"
$url = http://frontendserver
$SiteTemplate = "STS#0" # Basic TeamSite
$port = "80"

New-SPWebApplication -Name $webAppName -ApplicationPool $appPool -ApplicationPoolAccount (Get-SPManagedAccount $farmAcct) -DatabaseServer $AliasName -DatabaseName $Contentdatabase -Url $url -Port $port

Donde la variable $url contiene el valor de la dirección del servidor front-end de SharePoint asignado.

Lo interesante de la granja de SharePonit es que todos los servidores de SharePoint mantienen una copia de las aplicaciones Web  creadas.
          

Una guía para saber donde crear los servicios de aplicación esta en el siguiente enlace:

http://technet.microsoft.com/es-ES/library/jj219591(v=office.15).aspx

Una pequeña muestra del contenido a continuación:

Aplicación de servicio Recomendación de servidor
Servicios de Access Servidor front-end.
Servicios de Access 2010 Servidor front-end.
Servicio de administración de aplicaciones Servidor front-end.
Conectividad a datos empresariales Servidor front-end.
Servicios de Excel Servidor front-end o especializado.
Servicio de traducción automática Servidor de procesamiento por lotes.
Servicio de metadatos administrados Servidor front-end.
Servicio de configuración de suscripción de Microsoft SharePoint Foundation Servidor front-end.
PerformancePoint Servidor de procesamiento por lotes o especializado.
Conversión de PowerPoint Servidor de procesamiento por lotes.
Búsqueda Servidor de procesamiento por lotes o servidores especializados para la búsqueda.
Búsqueda Servidores que ejecutan componentes de búsqueda.
Búsqueda Servidores que ejecutan el procesamiento de consultas.
Búsqueda Servidores que ejecutan componentes de búsqueda.
Servicio de almacenamiento seguro Servidor front-end.
Recolección de datos de uso y estado  
Perfil de usuario Servidor front-end.
Perfil de usuario Servidor de procesamiento por lotes.
Servicio de gráficos de Visio Servidor front-end.
Word Automation Services Servidor de procesamiento por lotes.
Administración del trabajo Servidor de procesamiento por lotes.

Bueno amigos eso es todo por este articulo que dimos un vistazo a la arquitectura lógica de SharePoint 2013.

SharePoint4Fun!,

Juan Manuel Herrera Ocheita