SharePoint Latin Rotating Header Image

Configuración

Comando PSCONFIG para configurar nuestra granja SharePoint

Como es bien sabido por todos, nuestro producto favorito SharePoint tiene la capacidad de auto nombrar o auto definir los nombres de las bases de datos para la configuración, aplicaciones de servicio y contenido facilitando con ello cualquier proceso de aprovisionamiento y configuración. Sin embargo, muchas empresas cuentan con esquemas de nombramiento de bases de datos pre establecidos para poder facilitar el soporte a largo plazo de las mismas, por ejemplo, siguiendo un estandar de nombramiento de las bases de datos es mas facil para un administrador SQL realizar operaciones de mantenimiento o soporte. En ese sentido, hay ocasiones donde nos vemos forzados utilizar nombres específicos para nuestras bases de datos SharePoint, adicional los nombres auto generados de SharePoint son dificiles de mantener ya que normalmente cuentan con Guids como parte del mismo nombre. :( 


Existen diversas opciones para ser establecer los nombres de nuestras bases de datos SharePoint, como por ejemplo desde la herramienta central de administracion o via PowerShell, el día de hoy quiero compartir mi opción favorita, PSCONFIG.EXE.


Una vez que instalamos SharePoint sobre nuestro servidor de aplicaciones principal, podemos utilizar la aplicación PSCONFIG.exe ubicada en la ruta raíz de SharePoint para dar inicio a la creación y aprovisionamiento de las bases de datos de configuración de nuestra granja permitiéndonos definir su nombre tanto de base de datos de configuración como el de la herramienta central de administración, el comando es:


C:\Program Files\Common Files\microsoft shared\Web Server Extensions\14\bin>PSCONFIG -cmd -configdb -create -server sql_alias -database PROD_Farm_ConfigDB -user DOMAIN\SP_Farm -password password123 -passphrase “Client SharePoint Implementation” -admincontentdatabase PROD_Farm_CentralAdmin


El proceso tarda unos minutos y mediante la consola de comandos se nos va mostrando el estatus del proceso de aprovisionamiento:




Una vez que terminamos este proceso ejecutamos el SharePoint Product Configuration Wizard para definir el puerto de la herramienta central de administración.



Mi recomendación es que preguntas sobre el estandar de nombramiento de bases de datos que tu empresa o cliente utiliza, en caso de que no tenga, tu puedes proponer uno. Por ejemplo yo utilizo el siguiente: Ambiente_Tipo_Nombre en donde ambiente puede ser DEV, QA, UAT, PROD, PIL y el tipo Content,Farm,SA de Service Application y el nombre. EN este ejemplo vemos PROD_Farm_ConfigDB osea, la base de datos de configuracion de mi ambiente de produccion. :)

Configurar cuenta de usuario para administrar granja SharePoint

Para efectos de ser granular y especifico en cuanto a los permisos y privilegios de aquellos que pueden realizar operaciones de administración de una granja SharePoint, normalmente hacemos uso de distintas cuentas de usuario dedicadas solo a la administración de este producto. En este post te quiero compartir los pasos para configurar de forma apropiada cuentas de administración SharePoint y así delegar a otros de una manera administrada y gestionable la administración de SharePoint.

Los pasos son:

  • Crear una nueva cuenta de directorio activo
  • Agregar la nueva cuenta como miembro al grupo de administradores locales
  • Agregar la nueva cuenta como miembro al grupo de WSS_Admin_WPG
  • Agregar la nueva cuenta a la lista de Administradores de Granja en la Herramienta Central de Administracion de SharePoint
  • Ejecutar comando PowerShell para asignar el rol de SQL Shell Access Admin sobre la bases de datos a las que la nueva cuenta puede administrar

Crear una nueva cuenta de directorio activo

Se recomienda que creemos una nueva cuenta de directorio active dedicada solo para el administrador en cuestión, esto para efecto de separar justamente las cuenta típica del empleado que realiza las operaciones de administrador de la gestión de la plataforma. Adicional, no queremos que la cuenta de usuario de uso diario de nuestro administrador sea la que tiene permisos sobre toda la granja, recordemos que el también es un usuario de SharePoint y no hay razón alguna para usar su identidad de empleado como la identidad del administrador de este servicio. Por ello, recomendamos crear una nueva cuenta y además usar una nomenclatura que claramente especifique la naturaleza de la función. Ejemplo adm.hgonzalez en donde adm. refiere que es una cuenta de administración.

Agregar la nueva cuenta como miembro al grupo de administradores locales

Otro consejo es crear un grupo de dominio y agregar este grupo de dominio al grupo de administradores locales en el servidor en cuestión, de esta forma simplemente agregamos nuestras cuentas de administradores SharePoint sobre el grupo de dominio el cual a su vez es miembro del grupo de administradores locales. Un nombre sugerido para este grupo puede ser “SharePointLocalAdmins”.

Agregar la nueva cuenta de administrador al grupo local WSS_ADMIN_WPG

También se requiere agregar nuestra nueva cuenta como miembro del grupo local WSS_ADMIN_WPG o simplemente agregar el grupo de dominio “SharePointLocalAdmins” como miembro al grupo local WSS_ADMIN_WPG.

Agregar la nueva cuenta a la lista de Administradores de Granja en la Herramienta Central de Administracion de SharePoint

Se requiere que nuestra cuenta de administrador se registre en la lista de administradores de granja de la herramienta central de Administracion SharePoint.

Ejecutar comando PowerShell para asignar el rol de SQL Shell Access Admin sobre la bases de datos a las que la nueva cuenta puede administrar

La cuenta en cuestión debe de contar con el rol SharePoint Shell Access sobre las bases de datos tanto de configuración como de contenido a fin de tener los permisos y privilegios para hacer operaciones de administración mediante PowerShell sobre esas bases de datos. Para poder asignar dicho rol usamos el comando Add-SPShellAdmin DOMINIO\adm.hgonzalez otorgando permisos a la base de datos de configuración. Sin embargo, si quisiéramos otorgar privilegios para manipular otras bases de datos de SharePoint como de contenido o de configuración de aplicaciones de servicio usamos el comando Get-SPDatabase | Add-SPShellAdmin DOMAIN\adm.hgonzalez para otorgar dichos privilegios en todas las bases de datos de la granja.

 

Configurando correo de salida en SharePoint usando PowerShell

Una de las primeras características del producto SharePoint es la de permitir a los usuarios a suscribirse a las alertas. Las alertas son un mecanismo de notificación de cambios vía correo electrónico en listas o bibliotecas de documentos permitiendo al usuario enterarse de cualquier cambio que suceda. Para que esta funcionalidad trabaje adecuadamente se debe de especificar en la configuración de la granja SharePoint la dirección SMTP del servidor que mandara los correos electrónicos y también la dirección de correo electrónico usada para enviar las notificaciones. Normalmente especificamos esos valores de forma manual usando la herramienta central de administración, sin embargo, el día de hoy quiero mostrar como especificar esta configuración usando un script de PowerShell.


$webApp = Get-SPWebApplication –IncludeCentralAdministration – Identity http://splapp1:5555


$webApp.UpdateMailSettings(“smtp.splatin.com”,”collaboration@splatin.com”, “collaboration@splatin.com”,65001)


$webApp.Update()

Recuperando datos desde una bases de datos de contenido SharePoint existente en SQL Server

En SharePoint 2010 y 2013 los administradores SharePoint tenemos la posibilidad de recuperar información desde una base de datos de contenido SharePoint que no necesariamente este montada sobre nuestra granja sino más bien solamente restaurada en SQL Server permitiéndonos realizar nuestra recuperación en menos tiempo y sin tanta configuración. Explico, en pasadas versiones para poder recuperar información desde un respaldo de una base de datos de contenido SharePoint normalmente teníamos que montar la base de datos restaurada sobre nuestra granja SharePoint, usando tanto comandos stsadm como la herramienta central de administración. Con SharePoint 2010 y 2013 no necesariamente es el caso, podemos hacerlo como antes o simplemente usar la herramienta central de administración para explotar el contenido de una base de datos SharePoint montada simplemente en un servidor SQL Server reduciendo con esto los tiempos de nuestros acuerdos de servicio ‘SLAs” y claro, ser más proactivos en la recuperación de datos.


Veamos entonces como lograrlo.


Accedemos a la herramienta central de administración y damos clic sobre el menú de respaldos y restauración para posteriormente seleccionar la opcion de recuperación de datos desde una base de datos no adjuntada.


unattached01


Especificamos el nombre e instancia de nuestro servidor SQL Server o bien el SQL Alias si es el caso donde se encuentra adjuntada nuestro respaldo de la base de datos de contenido SharePoint, especificamos el nombre de la base de datos a la cual nos queremos conectar para obtener los objetos SharePoint que requerimos recuperar. Seleccionamos el tipo de recuperación que queremos hacer, por ejemplo, podemos recuperar una colección de sitios, un sitio web o una lista.


unattached02


Usamos el explorador para buscar en este caso la colección de sitios que nos interesa recuperar directamente sobre la base de datos de contenido adjuntada en SQL Server. Como podemos ver, SharePoint es capaz de presentar todas las colecciones de sitio existentes, así mismo, SharePoint es capaz de explorar sitios web dentro de las colecciones e incluso listas y librerías.


unattached03


Una vez que elegimos el objeto a recuperar especificamos una ruta compartida y un nombre de un archivo físico donde será respaldado el contenido proveniente de la base de datos en cuestión. Posteriormente damos iniciar al proceso de respaldo.


unattached04


También, podemos monitorear el proceso en ejecución.


unattached05


unattached06


Al terminar validamos el archivo de respaldo generado.


unattached07


Y para finalizar simplemente ejecutamos un comando PowerShell para realizar el proceso de restauración del respaldo en cuestión sobre una colección de sitios existente en nuestra granja. El comando para restaurar una colección de sitios respaldada es:


Restore-SPSite http://intranet/teams/sp -Path \\d21-da\Scripts\backup\sp.bak


Validamos entonces la restauración y removemos el respaldo de la base de datos adjuntada en SQL Server. Esta es una técnica que permite recuperar información de una respaldo, asegúrate de definir un tiempo de respaldo SQL valido para que con ello puedas ser capaz de definir lo que llamamos el tiempo aceptable de perdida de datos. Por ejemplo, si tus respaldos SQL Server se ejecutan al final del dia, esto quiere decir que solamente puedes recuperar información de un día anterior y que tu potencial perdida de datos es de horas.

Preparando los Pre-Requisitos en Windows Server 2012 para implementación SharePoint

Para poder instalar SharePoint se requieren de ciertos pre requisitos de software en cada servidor de la granja, adicional, una serie de configuraciones son requeridas para optimizar el uso de los recursos, en este video vemos la implementación de los pre-requisitos de SharePoint en una modalidad fuera de línea, vemos la configuración del SQL Alias para invocar al servidor SQL Server y también se comparte cuáles son las carpetas sugeridas para almacenar información interna de SharePoint y IIS.


Terminando este video ya estamos en condiciones de dar inicio a la configuración de una granja SharePoint, la cual también estaré compartiendo en otro video en el futuro.


Desde ya, gracias por suscribirte a mi canal de Youtube



Optimizando SQL Server para SharePoint de acuerdo a mejores practicas

En esta ocasión decidí grabar una breve demostración de cómo optimizar SQL Server 2008 R2 para trabajar con SharePoint. Básicamente recurrí a las mejores prácticas de SQL Server para SharePoint publicadas aquí y el resultado fue justamente las configuraciones mostradas en este breve video.


 


El ritual de instalación de los paquetes de idioma en SharePoint 2010

Cuando instalas el SharePoint 2010 usando los discos de instalación oficial, probablemente los binarios no cuentan con el Service Pack 1 o las CU que van surgiendo con el tiempo. Sin embargo hoy en día ya existe el disco de instalación de SharePoint con el Service Pack 1 integrado en el centro de descarga Microsoft de MSDN. Si de pura casualidad te toca instalar los paquetes de idioma sobre una granja que ya tienen SharePoint 2010 Service Pack 1 instalado entonces tienes que hacer la siguiente operación para asegurar la correcta configuración de los paquetes de idioma.


Lo primero es tener los paquetes de idioma para SharePoint Foundation y SharePoint Server, ¿estamos de acuerdo? Lo segundo es tener el service pack 1 de cada uno de los paquetes de idioma, tanto para SharePoint Foundation y SharePoint Server.


Que hay que descargar por cada idioma:


  • SharePoint Foundation 2010 (Idioma) Language Pack
  • SharePoint Foundation 2010 (Idioma) Language Pack Service Pack 1
  • SharePoint Server (Idioma) Language Pack
  • SharePoint Server (Idioma) Language Pack Service Pack 1

La teoría nos dice que hay que ejecutar de manera escalonada todos estos instaladores. Primero Foundation Language Pack, después Foundation Language Pack Service Pack 1, después Server Language Pack y después Server Service Pack 1 Language Pack y así sucesivamente por cada idioma.


Le llamamos Slipstream a la idea de consolidar en solo instalador el language pack original junto con su service pack, para solamente hacer una instalación permitiéndonos reducir el tiempo en el proceso mientras que aseguramos la aplicación de los correspondientes service packs.


Consideremos la siguiente estructura de carpetas:


image


Asegúrate de descargar sobre cada carpeta los instaladores correspondientes del idioma, tanto el language pack como el service pack del language pack correspondientemente. Para hacer Slipstream ejecutaremos varios comandos en alguna ventana de comandos, por ejemplo, el primer comando extrae del instaldor del language pack los archivos y los deposita dentro de la carpeta install, creando una nueva carpeta llamada Updates que por default existe en la estructura del paquete de idioma, posteriormente sobre la carpeta Updates depositamos los archivos del service pack del language pack correspondiente mediante el mismo comando de extracción, hacemos lo siguiente:


cd\
cd splp
cd Foundation
cd Spanish
SharePointLanguagePack.exe /extract:C:\SPLP\Foundation\Spanish\Install
spflanguagepack2010sp1-kb2460059-x64-fullfile-es-es.exe /extract:C:\SPLP\Foundation\Spanish\Install\Updates


cd\
cd splp
cd Foundation
cd Chinese
SharePointLanguagePack.exe /extract:C:\SPLP\Foundation\Chinese\Install
spflanguagepack2010sp1-kb2460059-x64-fullfile-zh-cn.exe /extract:C:\SPLP\Foundation\Chinese\Install\Updates


cd\
cd splp
cd Foundation
cd Portuguese
SharePointLanguagePack.exe /extract:C:\SPLP\Foundation\Portuguese\Install
spflanguagepack2010sp1-kb2460059-x64-fullfile-pt-br.exe /extract:C:\SPLP\Foundation\Portuguese\Install\Updates


cd\
cd splp
cd Server
cd Spanish
ServerLanguagePack.exe /extract:C:\SPLP\Server\Spanish\Install
serverlanguagepack2010sp1-kb2460056-x64-fullfile-es-es.exe /extract:C:\SPLP\Server\Spanish\Install\Updates


cd\
cd splp
cd Server
cd Chinese
ServerLanguagePack.exe /extract:C:\SPLP\Server\Chinese\Install
serverlanguagepack2010sp1-kb2460056-x64-fullfile-zh-cn.exe /extract:C:\SPLP\Server\Chinese\Install\Updates


cd\
cd splp
cd Server
cd Portuguese
ServerLanguagePack.exe /extract:C:\SPLP\Server\Portuguese\Install
serverlanguagepack2010sp1-kb2460056-x64-fullfile-pt-br.exe /extract:C:\SPLP\Server\Portuguese\Install\Updates


Una vez que tenemos todos los paquetes de idioma con sus correspondientes service packs integrados procedemos a instalar de la siguiente manera de esta forma a mí me ha funcionado usando el instalador de la carpeta Install para foundation y server:


C:\SPLP\Foundation\Spanish\Install\setup.exe
C:\SPLP\Server\Spanish\Install\setup.exe
Ejecutar el configuration wizard de SharePoint


C:\SPLP\Foundation\Chinese\Install\setup.exe
C:\SPLP\Server\Chinese\Install\setup.exe
Ejecutar el configuration wizard de SharePoint


C:\SPLP\Foundation\Portuguese\Install\setup.exe
C:\SPLP\Server\portuguese\Install\setup.exe
Ejecutar el configuration wizard de SharePoint


Espero que te sea util este procedimiento ya que cuando tenemos más de un servidor Web Front End en una granja SharePoint, aplicar los paquetes de idioma y su correspondiente service pack 1 se vuelve una tarea exponencialmente aburrida.


Saludos.

Que involucra configurar la aplicación de servicio de perfiles de usuario de SharePoint 2010

Hace poco levante un ambiente de desarrollo SharePoint 2010 en modalidad Limited Farm Deployment. Al configurar el User Profile Service Application decidi grabar la sesión y el resultado es un nuevo video publicado en mi canal de youtube.


Que involucra configurar la aplicación de servicio de perfiles de usuario de SharePoint 2010.


  • Utilizar la cuenta SPFarm
  • En el servidor donde se ejecutara el servicio:
  • Otorgar el permiso de Allow log on locally a la cuenta SPFarm
  • Agregar a SPFarm como administrador local
  • Crear un Web Application dedicado a My Site o bien crear un Site Collection en cualquier Web Application que utiliza la plantilla My Site Host ubicada en la pestaña de Empresa
  • Crear una instancia de la aplicación de servicio User Profile Service Application especificando la dirección URL del My Site Host resultante y proporcionando el application pool que va a ejecutar el servicio
  • Hacemos un IISReset
  • Asignar administradores de la aplicación de servicio recién creada
  • Iniciar los servicios de User Profile Service Application y User Profile Sincronization Service dentro la opción de Services in server
  • Configurar el conecto hacia el directorio activo para seleccionar la unidad organizacional que contiene a los usuarios que se estarán sincronizando
  • Configurar la periodicidad de ejecución de los Jobs de sincronización de perfiles
  • Asegurar que la aplicación de servicio de gestión de metadatos este encendida y bien configurada
  • Ejecutar una sincronización de perfiles full

Aquí el video:


Documentando Granjas SharePoint con SharePoint Documentation Toolkit

Hoy quiero comentar sobre una herramienta que todo consultor o empresa que ofrece servicios SharePoint debería de tener. Sucede que con cada nuevo cliente y/o proyecto tenemos que conocer la granja donde potencialmente estaremos soportando o instalando nuestros desarrollos, en ese sentido hay que ser muy cuidadosos de no impactar configuración existente y sobre todo de tener el conocimiento de la configuración para asegurar que los movimientos que haremos no impacten a otros y si así fuese el caso, saber cómo estaba configurado antes. En el pasado he tenido la experiencia de conocer una empresa que se metió en graves problemas por no haber sido lo suficientemente cuidadosos de documentar la configuración de la granja de producción antes de implementar algunos paquetes de solución con desarrollo personalizado en la granja de cliente, termino siendo un desastre.


Así mismo, empresas que han invertido millones en su plataforma de colaboración basada en SharePoint también deben de mantenerse al día y conocer la configuración que se tiene implementada. Recuerden que cuando tenemos un entorno productivo y somos una empresa grande es muy probable que tengamos más de una granja, más de un ambiente, con múltiples servidores probablemente balanceados que deberán todos contar con el mismo nivel de configuración y de paquetes de actualización, desde la perspectiva SharePoint todos sabemos que nuestros Web Front Ends deben de estar idénticos en cuanto a configuración se refiere y claro esto se vuelve un reto mantenerlos al día.


Es aquí donde SharePoint Documentation Toolkit  de Acceletario, LTD entra a la escena. SPDocKit es una herramienta de documentación que asiste a los administradores y consultores SharePoint en conocer, comparar y rastrear los cambios de configuración de granjas SharePoint 2007 y 2010 en tan solo 3 clics, permitiendo sin duda un conocimiento mucho más detallado de la configuración en minutos.


Características:


  • Genera documentación de granjas SharePoint: Simplemente instalando y/o ejecutando en cualquieras de los servidores de una granja SharePoint 2010 o 2007 puedes generar un documento de Word o PFD al vuelo tras revisar los aspectos de configuración que tú mismo seleccionas para depositarlos en tablas y textos dentro del documento. Es muy extensa toda la configuración que se puede documentar y sin duda presenta una radiografía con la que puedes entender en qué estado de configuración está tu granja.
  • Explora la configuración de tus granjas: La interface visual de Documentation Toolkit ofrece una vista de árbol con la cual puedes explorar mediante nodos y vistas los distintos elementos de configuración que tienes en tu granja permitiendo consultar en el momento y totalmente en línea la información.
  • Documenta contraseñas y llaves de producto: Existe distintas modalidades de uso de este producto y uno de ellos nos permite contar con un acceso total a la información de nuestra implementación. Entre ellas contraseñas y claves de producto, podemos configurar una base de datos SQL para almacenar el estado de las configuraciones y mantener con el tiempo esa información.
  • Comparación de la configuración entre granjas: Valida los cambios de configuración que pueden existir en los servidores entre granjas SharePoint. La opción de comparación te muestra las diferencias.

Aqui un video de demostracion:



¿Por qué utilizar SQL Server 2012 en SharePoint 2010?

En una reunión de trabajo, de una manera enérgica pregunta el director de infraestructura que si porque se recomienda utilizar SQL Server 2008 R2 64 Bit para instalar SharePoint 2010 si también SQL Server 2005 y 2008 lo soportan casi casi dejando ver que es solo por cuestiones de apalancamiento de licencias por parte de Microsoft. Y bueno mi respuesta fue que es recomendable siempre utilizar las versiones más recientes del software tanto del sistema operativo como también de SQL y la razón es porque algunas características de funcionalidad que van emergiendo fueron construidas posteriormente o requieren software más reciente y si las necesidades que tenemos están en torno a esas características, sin duda conviene invertir.

Un ejemplo es PowerPivot no corre sobre versiones de SQL distintas a SQL 2008 R2 e incluso aproveché para dar otro ejemplo y mencionar que SQL Server 2012 permite agregar como aplicación de servicio en SharePoint 2010 a SQL Server Reporting Services y PowerPivot, gracias a esto, la administración, gestión, respaldo, configuración ahora formaría parte de la pila funcional de SharePoint y no de SQL por ende menos complejidad al modelo de la solución desde la perspectiva administración y mantenimiento. También algo muy importante mencionar es que al tener Reporting Services como aplicación de servicio en SharePoint 2010 entonces ahora se soportan las alternativas de autentificación disponibles en SharePoint abriendo a un mayor rango de opciones y posibilidades de reporteo que antes no se tenían por la limitantes de seguridad y autentificación. Si tu cliente requiere ofrecer reportes o inteligencia de negocio para clientes, proveedores o algún otro en la cadena de valor, entonces SharePoint 2010 y SQL Server 2012 ofrecen la mejor opción para escenarios de extranet para entrega de BI.

Así es amigos, desde ya deberíamos de estar implementando SharePoint 2010 con SQL Server 2012 para sacar una mayor ventaja en las características de BI disponibles que podemos configurar en SharePoint 2010 así como también las de disponibilidad y desempeño que el mismo SQL Server 2012 aporta a la mesa.

PD. Me parece que desde la perspectiva licenciamiento también Microsoft ya está entregando SQL Server 2012 como parte de los Enterprise Agreements así que ya deberías de saber integrar SQL Server 2012 con SharePoint 2010.

Aquí unos recursos:

Suerte!