Archivo de la etiqueta: PowerShell

SharePoint Online – PowerShell

Vuelvo despues de un tiempo retirado de mi Blog… Esta vez vengo con información del Shell de SharePoint Online. Como ocurria con el Shell para las diferentes versiones on-premise, el Shell de administración de SharePoint Online es un módulo de Windows PowerShell que puede utilizar para administrar sitios y colecciones de sitios de SharePoint Online.

Para hacer uso del Shell de administración de SharePoint Online, es necesarios instalarlo previamente en la maquina local donde se vaya a ejecutar.  Este Shell (Microsoft.Online.SharePoint.PowerShell) puede descargarse desde: https://www.microsoft.com/en-us/download/details.aspx?id=35588. Una nueva versión ha sido publicada el 15/09/2017, con mejoras funcionales y muevos objetos.

Las operaciones de la línea de comandos de Windows PowerShell constan de una serie de comandos o cmdlets con un conjunto de valores y parámetros. Los diferentes comandos se identifican en base a la acción que se indica en el prefijo de este:

  • Set-XXX
  • Get-XXX
  • Remove-XXX
  • New-XXX
  • Add-XXX
  • Etc.

Referencia de comandos del Shell de adminsitración de SharePoint Online: https://technet.microsoft.com/es-es/library/fp161364.aspx. Ademas si quieres acceder al listado de todos los comandos existentes a traves del propio PowerShell puedes hacerlo de la siguiente manera:

# Lista de comandos
Get-Command –Module Microsoft.Online.SharePoint.PowerShell

Antes de lanzar ningún comando sobre SharePoint Online es necesario autenticarse como usuario. Además es necesario ser Administrador de SharePoint para realizar estas acciones a través del Shell.

Para realizar la autenticación a través de PowerShell es necesario hacer uso del comando “Connect-SPOService“:

# Conexion con SharePoint Online 
$adminEmail = "mi_usuario@mi_dominio.onmicrosoft.com"
$adminUrl = "https://mi_dominio-admin.sharepoint.com"
$adminCredentials = Get-Credential -UserName $adminEmail -Message "Acceso a la Admin de SPO"
Connect-SPOService -Url $adminUrl -Credential $adminCredentials

Tras la conexión con SharePoint Online, ya es posible lanzar diferentes comandos, como los siguientes:

# Listado de todas las propiedades de un objeto
Get-SPOWebTemplate |select *

# Obtiene las plantillas de sitio de SharePoint
Get-SPOWebTemplate |Sort-Object DisplayCategory |Format-Table Name,Title,DisplayCategory

# Listado de TODOS LOS SITIOS (incluyendo Sitios Personales)
Get-SPOSite -IncludePersonalSite:$true -Limit All |Sort-Object Template |Format-Table Url,Template,LocaleId,Owner,StorageUsageCurrent

# Listado de los SITIOS PERSONALES (sitios con plantilla SPSPERS#10)
Get-SPOSite -IncludePersonalSite:$true -Limit All |where { $_.template -eq 'SPSPERS#10' } |Sort-Object Owner |Format-Table Url,Owner,StorageUsageCurrent

# Listado de Microsoft Groups (sitios con plantilla GROUP#0)
Get-SPOSite -Filter {Template -eq "GROUP#0"} -Limit All |Sort-Object StorageUsageCurrent |Format-Table Url,Title,StorageUsageCurrent,LastContentModifiedDate

Workflows en correos entrantes en Biblioteca de Documentos de SharePoint 2010

sharepoint2010 Una de las ultimas cosas con la que me he pegado, es saber por que los Workflows de una biblioteca de documentos, no se lanzaban, en el caso únicamente de añadir documentos a través de email.

Para el que no lo sepa, SharePoint 2010 incluye la funcionalidad de poder añadir información a una biblioteca de documentos, a través de email, es decir: si quieres añadir un archivo concreto a una librería y no puedes acceder al entorno de SharePoint, siempre tienes la posibilidad de enviar un email con dicho archivo, a una cuenta en concreto (esto debes haberlo configurado previamente).

declarativeworkflow

Volviendo al problema, tengo una biblioteca de documentos, donde hay un workflow personalizado, el cual se lanza cuando se añade un elemento. Esto funciona correctamente, si subes el documento a través del interface web o usando el explorador (mediante el protocolo WebDav)… pero cuando se suben a través de email, el workflow no se lanza!!!

Buceando en Internet, he visto que para habilitar esto, tiene que estar activa la propiedad “DeclarativeWorkflowAutoStartOnEmailEnabled“.

Como es habitual, esto puede hacerse usando bien STSADM o PowerShell, únicamente indicar, que los comandos a través de STSADM desde la versión de SharePoint 2007 no denegrían utilizarse (esta marcado como deprecated), Microsoft te recomienda el uso de PowerShell.

Procedimiento con STSADM:

1) Primero debemos verificar si este parámetro se encuentra activo o no, para ello lanzamos el siguiente comando:

stsadm -o getproperty -pn declarativeworkflowautostartonemailenabled

2) Verificamos el valor de la propiedad “Value” y en el caso que sea “no” deberíamos activarlo

declarativeworkflow1

3) Para activarlo ejecutamos el siguiente comando:

stsadm -o setproperty -pn declarativeworkflowautostartonemailenabled -pv true

declarativeworkflow2

Procedimiento con PowerShell:

1) Primero debemos verificar si este parámetro se encuentra activo o no, para ello lanzamos el siguiente comando:

$spWebService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$spWebService.DeclarativeWorkflowAutoStartOnEmailEnabled

2) Verificamos el valor que devuelve y en el caso que sea “False” deberíamos activarlo
3) Para activarlo ejecutamos el siguiente comando:

$spWebService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$spWebService.DeclarativeWorkflowAutoStartOnEmailEnabled = $true
$spWebService.Update()

Puedes consultar mas información sobre la propiedad DeclarativeWorkflowAutostartOnEmailEnabled aquí.

 

Script de PowerShell para rellenar una lista de SharePoint con elementos

powershell Este ejemplo es válido tanto para plataformas SharePoint 2010 como SharePoint 2013. Viene motivado por la necesidad de probar los limites del producto en cuanto a vistas de listas se refiere.

Tanto la versión 2010 como 2013 tienen los mismos limites en cuanto a listas/bibliotecas se refiere en cuanto a:

  • Numero de elementos por lista: 30.000.000
  • Limitación de vista de lista: 5000 elementos
  • Tamaño de filas de lista: 8.000 bytes por fila

Viendo estas limitaciones, aquí tenéis un script de PowerShell con el que podréis añadir de forma automática miles de elementos en una lista:

[System.Reflection.Assembly]::LoadWithPartialName(”Microsoft.SharePoint”)
function PopulateList
{
    param ($ListURL, $count)
    $mySite = new-object Microsoft.SharePoint.SPSite($ListURL)
    $myWeb = $mySite.OpenWeb()
    $mySrcList = $myWeb.GetList($ListURL)
    $itemCount=0
    write-host "Preparando la lista para la carga de datos: " $ListURL
    write-host "-----------------------------------------------------------------"
    while ($itemCount -lt $count)
    {
        $itemCount=$itemCount+1
        write-host "Creando elemento:" $itemCount
        $listItem = $mySrcList.Items.Add()
        $title="Titulo del elemento " + $itemCount
        $listItem["Title"]=$title
        $listItem.Update()
    }
    $myweb.Dispose()
    $mySite.Dispose()
}
#---------------------------------------------------------------
#Para usar este función solo tienes que llamarla pasando como parámetro la lista y el numero de elementos a crear
$sitecollection="http://intranet/sitio/Lists/listaPrueba/"
PopulateList $sitecollection 6000
#---------------------------------------------------------------

 

Hay que destacar, que la lista (como requisito) unicamente ha de tener el campo “Titulo” (campo por defecto en listas que hereden del tipo de contenido “Elemento”), único campo que rellena el script.

 

ViewFormPagesLockdown para aumentar la seguridad en SharePoint 2010

sharepoint2010 Ayudando a un amigo, vimos que en portales públicos en los que se utiliza SharePoint 2010, puedes tener una mala configuración que a nivel de seguridad, puede ser problemático.

Cuando creas un portal publico (usando las características de Publicación) basado en SharePoint, has de configurar el acceso de usuarios, como anónimo, por lo que por defecto permite que cualquier usuario acceda a los siguientes recursos:

  • /_layouts/viewlsts.aspx
  • /Lists/[ListName]/AlItems.aspx

Esto es un problema de seguridad, ya que estas dando una información muy importante a usuarios anónimos, que podrían usar en tu contra… pero no hay problema ya que SharePoint trae una característica oculta a nivel de Site, llamada ViewFormPagesLockdown, que deshabilita el acceso a estos recursos de forma anónima.

Para activar esta funcionalidad, hay que utilizar un par de comandos de PowerShell:

1) Obtenemos el GUID de la característica ViewFormPagesLockdown, la cual como he comentado esta oculta con el siguiente comando:

Get-SPFeature | where { $_.DisplayName -eq "ViewFormPagesLockdown"}

ViewFormPagesLockdown

2) Una vez tenemos el GUID o identificador, lo que hacemos es activarlo:

Enable-SPFeature -url http://sharepoint -identity 7c637b23-06c4-4724-9a9a-7c175762c5c4 -confirm:$false

Tras este cambio, los usuarios tendrán que autenticarse, para acceder a estos recursos.

IMPORTANTE: Puedes tener problemas si dentro de esta colección de sitio, tienes subsitios de tipo Blog, en los que los usuarios pueden realizar comentarios sobre post o similares… para solucionar este tipo de problema, en el blog de sharepointblues.com te explican como se puede solucionar.

Listado de permisos de usuarios de un sitio en SharePoint 2010

powershellUna de las ultimas cosas que me han solicitado es recuperar todos los usuarios y sus permisos de una colección de sitio o subsitio en SharePoint 2010

La forma mas rápida que se me ocurrió es la de crear un script de PowerShell para ello. Como creo que os podría ser de utilidad, lo comparto con todos vosotros:

function Get-UsersPermissions([string]$portalurl, [String[]]$excludewebs, [string]$onesite) 
{ 
    [void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") 
    $farm = [Microsoft.SharePoint.Administration.SPFarm]::Local 
	#añade la barra si no existe
    if (-not $portalurl.EndsWith("/")) { $portalurl = $portalurl + "/" } 
	#recorre todos los servicios de la granaja
    foreach ($spService in $farm.Services) 
	{ 
        if (!($spService -is [Microsoft.SharePoint.Administration.SPWebService])) { continue; } 
        foreach ($webApp in $spService.WebApplications) 
		{ 
            if ($webApp -is [Microsoft.SharePoint.Administration.SPAdministrationWebApplication]) { continue; } 
			$webAppUrl = $webApp.GetResponseUri('Default').AbsoluteUri 
			if ($webAppUrl.ToUpper() -eq $portalurl.ToUpper())
			{ 
				#recorre las colecciones que existen en la aplicacion web
				foreach ($site in $webApp.Sites) 
				{ 
					#si existe algun parametro 
					if (($onesite -ne $null) -and ($onesite -ne "")) 
					{ 
						#verifica si se ha incluido el parametro Web
						if ($site.Url.ToUpper() -ne $onesite.ToUpper()) { continue; } 
					} 
					#recorre los sitios que existen en la coleccion
					foreach ($web in $site.AllWebs) 
					{ 
						if ($excludewebs -contains $web.Url) 
						{ 
							Write-Host "Se ha excluido el sigioente sitio: " $web.Url 
							continue 
						} 
						foreach ($user in $web.SiteUsers)
						{ 
							#excluye al usuario: sharepoint\system 
							if ($user.Loginname.StartsWith("SHAREPOINT\")) { continue; } 
							#recupera la informacion a mostrar
							$data = @{ 
										"Coleccion" = $site.Url 
										"Url sitio" = $web.Url 
										"Nombre sitio" = $web.Title 
										"Usuario" = $user.Loginname 
										"Nombre" = $user.Name 
										"Roles" = $user.Roles 
										"Grupos" = $user.Groups 
							} 
							New-Object PSObject -Property $data 
						} 
						$web.Dispose(); 
					} 
					$site.Dispose() 
				} 
			} 
		} 
	} 
}

#---------------------------------------------------------------
#Opcion 1: Listas de los usuarios y sitio del la Aplicacion Web: http://intranet, pero solo muestra los usuarios y permisos del subsitio: http://intranet/sites/test
# Get-UsersPermissions -portalurl:http://intranet/  -onesite:http://intranet/sites/test | Out-GridView
#---------------------------------------------------------------
#Opcion 2: Listas de los usuarios y sitio del la Aplicacion Web http://intranet, pero excluye los 3 sitios: /gastos, /docs y /rrhh
# Get-UsersPermissions -portalurl:http://intranet/ -excludewebs:@('http://intranet/gastos','http://intranet/docs','http://intranet/rrhh')  | Out-GridView
#---------------------------------------------------------------
#Opcion 3: Lista todas los sitios y usuarios de la Aplicacion Web: http://intranet
# Get-UsersPermissions -portalurl:http://intranet/ | Out-GridView
#---------------------------------------------------------------

DisableLoopbackCheck en SharePoint 2010

Uno de los problemas con el que nos podemos encontrar los desarrolladores de SharePoint 2010, es que cada vez que intentamos acceder a sitios de nuestros entornos de desarrollo o preproducción de SharePoint, que se habíamos creado previamente, nos pide en repetidas ocasiones (las tres de rigor) su usuario y contraseña antes de devolver un error 401.1 Access Denied y una entrada en el Visor de Eventos de Windows.

En principio esto no debe de ser un problema ya que ningún usuario usa directamente los servidores de la granja de SharePoint para navegar por los sitios ahí hosteados. Pero ¿y si es un servidor de desarrollo o pruebas? En estos casos es obligatorio que podamos acceder a los sitios sin que este comportamiento ocurra.

Este comportamiento del sistema, es una característica de seguridad introducida desde el Service Pack 1 de Windows Server 2003 y está presente hasta las versiones actuales de Windows Server 2008 R2. Básicamente lo que hace es bloquear el acceso a una Web Application usando el FQDN, si esto sucede la característica entra en acción y bloquea este acceso enviando un error 401.1 Access Denied. ¿Por qué se introdujo esta característica? Pues porque existían varios ataques que se basaban en reflección para engañar a IE y hacerle creer que se estaba trabajando de manera local y así burlar muchas restricciones de seguridad.

¿Como podemos solucionar este problema (siempre y cuando se traten de entornos no productivos)? Existen dos métodos .. uno a través de la ejecución de un comando de PowerShell y la segunda añadiendo una clave en el Registro de Windows.

1) Ejecución de este comando PowerShell:

New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -value "1" -PropertyType dword

En la siguiente imagen puede apreciarse la ejecución de este comando:

2) Modificando directamente el Registro de Windows:

– Pincha en el botón de Inicio o presiona la tecla Windows + X (dependiendo la versión de Windows), pincha en Ejecutar, escribe: “regedit” y presiona Intro.
– En el editor del Registro de Windows, localiza la siguiente clave: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
– Pincha con el botón derecho del ratón en Lsa, selecciona nueva Valor de DWORD (32 bits)


– Introducimos el nombre “DisableLoopbackCheck” y presionamos Intro.
– Pinchamos con el botón derecho del raton sobre esta nueva clave “DisableLoopbackCheck“, y seleccionamos Modificar.
– Introducimos un “1” en el campo Información del valor  y presionamos Intro.


– Cerramos el editor del Registro de Windows y reiniciamos el servidor para que los cambios tengan efecto.

Para información mas detallada sobre este problema, podéis consultar el KB896861.

 

Eliminar características de la base de datos de contenido con PowerShell

Una de mis tareas es revisar el Analizador de mantenimiento de SharePoint 2010, donde quedan registrados problemas que pueden hacer que una granja de SharePoint tenga problemas de seguridad, escalabilidad, rendimiento…

Uno de los problemas que he detectado y que viene siendo recurrente, es soluciones han sido eliminadas, antes de que las características correspondientes hayan sido desactivadas de colecciones de sitios y sitios.

Este problema queda registrado en el  Analizador de mantenimiento, con la categoría a nivel de granja: “Missing server side dependencies“.

Dentro de esta categoría, puedes encontrar registros como el siguiente, donde se detallo el problema:

[MissingFeature] Database [_WSS_DSI01] has reference(s) to a missing feature: Id = [e8389ec7-70fd-4179-a1c4-6fcb4342d7a0]. The feature with Id e8389ec7-70fd-4179-a1c4-6fcb4342d7a0 is referenced in the database [_WSS_DSI01], but is not installed on the current farm. The missing feature may cause upgrade to fail. Please install any solution which contains the feature and restart upgrade if necessary.

Este mensaje de error indica un nombre de base de datos de contenido (_WSS_DSI01) y el identificador de la característica (e8389ec7-70fd-4179-a1c4-6fcb4342d7a0), lo malo es que este error, no informa sobre los sitios o colecciones de sitios donde la característica existe y además, aunque supiéramos donde se ha activado esta característica, no es posible desde el interfaz de usuario desactivarla, ya que dicha solución se ha eliminado de la granja.

El siguiente script de PowerShell, nos informa de que sitios o colecciones de sitio de la base de datos de contenido, contienen la referencia a esta característica y fuerza la desactivación de de esta.

function Remove-SPFeatureFromContentDB($ContentDb, $FeatureId, [switch]$ReportOnly)
{
    $db = Get-SPDatabase | where { $_.Name -eq $ContentDb }
    [bool]$report = $false
    if ($ReportOnly) { $report = $true }
    $db.Sites | ForEach-Object 
    {
        Remove-SPFeature -obj $_ -objName "site collection" -featId $FeatureId -report $report
        $_ | Get-SPWeb -Limit all | ForEach-Object 
        {
            Remove-SPFeature -obj $_ -objName "site" -featId $FeatureId -report $report
        }
    }
}

function Remove-SPFeature($obj, $objName, $featId, [bool]$report)
{
    $feature = $obj.Features[$featId]
    if ($feature -ne $null) 
    {
        if ($report) 
        {
            write-host "Feature found in" $objName ":" $obj.Url -foregroundcolor Red
        }
        else
        {
            try 
            {
                $obj.Features.Remove($feature.DefinitionId, $true)
                write-host "Feature successfully removed from" $objName ":" $obj.Url -foregroundcolor Red
            }
            catch 
            {
                write-host "There has been an error trying to remove the feature:" $_
            }
        }
    }
    else 
    {
        #write-host "Feature ID specified does not exist in" $objName ":" $obj.Url
    }
}

 

Si únicamente queremos obtener el listado de sitios y colecciones de sitios, donde se referencia esta característica, deberás utilizando de la siguiente forma:

Remove-SPFeatureFromContentDB -ContentDB "_WSS_DSI01" -FeatureId "e8389ec7-70fd-4179-a1c4-6fcb4342d7a0" –ReportOnly

 

Si por el contrario, además de obtener el listado, deseas eliminar las referencias de la base de dato de contenido, deberás utilizarlo como anteriormente, el único cambio es que has de eliminar el parámetro “–ReportOnly”:

Remove-SPFeatureFromContentDB -ContentDB "_WSS_DSI01" -FeatureId "e8389ec7-70fd-4179-a1c4-6fcb4342d7a0"

 

Una vez hayas eliminado todas las referencias erróneas, es necesario volver a analizar  la categoría: “Missing server side dependencies” dentro del Analizador de mantenimiento, para comprobar que los errores han desaparecido.

Referencia: get-spscripts.com

 

Configurar Remote Blob Storage (RBS) en SharePoint 2010

Con este post quiero explicar como se ha de configurar Remote Blob Storage o RBS en SharePoint 2010. Parto que todos sabemos que es RBS y los tipos de contenido Blob, únicamente aclarar que este sistema de almacenar ficheros en File System es algo propio de SQL Server 2008 llamado FILESTREAM y SharePoint 2010 lo único que hace es a través de la siguiente configuración, permitir que dichos ficheros (han de ser de gran tamaño) se almacenen en el sistemas de archivos en vez de en base de datos con lo cual, se tenga una mayor velocidad de acceso…

Requisitos: La versión mínima de SQL Server seria: Microsoft SQL Server 2008 R2, Microsoft SQL Server 2008 con Service Pack 1 (SP1) y Cumulative Update 2.

Aclarado esto, vamos a ver los pasos a seguir a la hora de activar RBS en una base de datos de contenido de SharePoint 2010 y antes de nada debemos asegurarnos que la cuenta que vamos a utilizar es miembro del grupo de Administradores de SharePoint y miembro de SQL Server con los roles de dbcreator y securityadmin.

1) Partimos que tenemos claro en que base de datos de contenido de SharePoint vamos a habilitar RBS, así que lo primero es habilitar FILESTREAM en nuestro servicio de SQL Server, para ello:

Abrimos “SQL Server Configuration Manager”, seleccionamos “SQL Services” y en la ventana de la derecha, accedemos a las propiedades de “SQL Server”. Esto nos abrirá una nueva ventana sobre la que pincharemos en la pestaña “FILESTREAM” y activaremos las siguientes opciones:

  • “Enable FILESTREAM for Transact-SQL access” 
  • “Enable FILESTREAM for file I/O streaming access” 
  • “Allow remote clients to have streaming access to FILESTREAM data”

2) Tras habilitar en el servicio SQL Server el FILESTREAM, debemos activarlo en SharePoint, para ello abrimos “SQL Server Management Studio”, y ejecutamos el siguiente script sql:

Use [master]
Exec sp_configure filestream_access_level, 2
Reconfigure

Una vez ejecutado, abrimos el “SharePoint 2010 Management Shell” para identificar el nombre de la base de datos de nuestra Web Application (también puede hacerse de un Site Collection) y escribimos:

$db = Get-SPContentDatabase –WebApplication http://miintranet
$db

Tras obtener el nombre (Name) de la base de datos, volvemos a  abrir el “SQL Server Management Studio” y ejecutamos las siguientes sentencias sql:

  • Creación de una clave maestra para nuestra base de datos:
Use [DemoContentDB]
If not exists (select * from sys.symmetric_keys where name =
N'##MS_DatabaseMasterKey##')create master key encryption by
password = N'Admin Key Password !2#4'
  • Creación del filegroup:
If not exists (select groupname from sysfilegroups where groupname=
N'RBSFilestreamProvider')alter database [DemoContentDB] 
add filegroup RBSFilestreamProvider contains filestream
  • Una vez tenemos el filegroup, debemos añadir el archivo de filestream (en este ejemplo lo creamos en la ruta C:\RBSDataStore):
Alter database [DemoContentDB] add file (name = 
RBSFilestreamFile, filename = 'C:\RBSDataStore') to filegroup RBSFilestreamProvider

Para comprobar que todo se ha creado correctamente, abrimos el explorador de archivos y comprobamos que la carpeta ha sido creada:

3) El siguiente paso es instalar el proveedor RBS en los servidores de SQL Server y SharePoint 2010, para ello debemos descargar el paquete “RBS.msi” de Microsoft: http://go.microsoft.com/fwlink/?LinkID=177388 y realizar la instalación desde consola, para ello:

  • Accedemos al servidor SQL Server de la granja
  • Copiamos el paquete descargado “RBS.msi” a: “C:\SPSetupInfo\
  • Abrimos la “Consola de Windows” y ejecutamos el siguiente comando en “C:\SPSetupInfo\“:
msiexec /qn /lvx* rbs_install_log.txt /i RBS.msi TRUSTSERVERCERTIFICATE=true FILEGROUP=PRIMARY DBNAME="DemoContentDB" DBINSTANCE="SQL\SQLSP" FILESTREAMFILEGROUP=RBSFilestreamProvider FILESTREAMSTORENAME=FilestreamProvider_1

Los dos únicos parámetros que debemos tener en cuenta son el nombre de la base de datos y la instancia de SQL Server.

La ejecución de este comando puede tardar varios minutos, puedes verificar si ha terminado, desde el administrador de tareas de Windows buscando el proceso “msiexec.exe“.

Una vez finalizado debemos comprobar en el archivo de log que deja en  “C:\SPSetupInfo\rbs_install_log.txt’” que la instalación ha ido correcta, para ello buscamos casi al final del archivo el siguiente mensaje:

 Si todo ha ido correctamente, debemos instalar el anterior paquete en todos los servidores de SharePoint de la granja:

  • Accedemos al resto de servidores de SharePoint 2010 de la granja
  • Copiamos el paquete descargado “RBS.msi” a: “C:\SPSetupInfo\
  • Abrimos la consola de Windows y ejecutamos el siguiente comando en “C:\SPSetupInfo\“:
msiexec /qn /lvx* rbs_install_log.txt /i RBS.msi DBNAME="DemoContentDB" DBINSTANCE="SQL\SQLSP" ADDLOCAL=Client,Docs,Maintainer,ServerScript,FilestreamClient,FilestreamServer

Los dos únicos parámetros que debemos tener en cuenta son el nombre de la base de datos y la instancia de SQL Server. Se paciente porque este proceso tardara unos minutos en cada uno de los servidores de la granja.

Una vez finalizado debemos comprobar que las bases de datos se han creado en nuestra base de datos de contenido “DemoContentDB”, así que volvemos a  abrir el “SQL Server Management Studio”, navegamos hasta la base de datos y verificamos que nuevas tablas con el prefijo “mssqlrbs_” han sido creadas:

4) Tras configurar RBS, solo queda activar y especificar el proveedor en SharePoint 2010, por lo que:

  • Volvemos a abrir el “SharePoint 2010 Management Shell” y ejecutamos el siguiente script:
$db = Get-SPContentDatabase -Site http://miientranet/sitios/DemoSite
$db
$rbss = $db.RemoteBlobStorageSettings
$rbss | format-list
$rbss.Installed()
$rbss.Enable()
$rbss.SetActiveProviderName($rbss.GetProviderNames()[0])
$rbss | format-list

El único que parámetro que hay que indicar es la url de la colección de sitio donde debemos activarlo.

5) El ultimo paso es comprobar que los ficheros que subimos a nuestro sitio, se están almacenando físicamente en disco en vez de hacerlo en base de datos, para ello subimos varios documentos a SharePoint y tras hacerlo, comprobamos como en el directorio “C:\RBSDataStore” se ven reflejados:

Crear una Colección de Sitio en una nueva base de datos de contenido en SharePoint 2010

Por defecto, SharePoint 2010 al crear una Aplicación Web (o Web Application), internamente genera una nueva base de datos de contenido, donde almacenará toda la información que haya dentro de este nuevo sitio, es decir, la información de Colecciones de Sitios y Subsitios…

Se nos puede dar el caso que queramos, por diferentes motivos (mantenimiento, escalabilidad, seguridad, etc.), crear una Colección de Sitio en una base de datos diferente, a la que tiene por defecto una Aplicación Web… en ese caso y como desde la interface Web de SharePoint 2010 no se permite realizar este tipo de acciones, debemos recurrir a un pequeño script de PowerShell, con el que podremos hacerlo de una forma muy sencilla.

El siguiente script crea una una Colección de Sitio en una nueva base de datos:

$w = Get-SPWebApplication -Identity "http://miintranet"
New-SPContentDatabase "DemoContentDB" -DatabaseServer "localhost\SharePoint" -WebApplication $w
New-SPSite "http://miintranet/sitios/DemoSite" -OwnerAlias "SPDOMAIN\omartin" -ContentDatabase "DemoContentDB" -Name "Demo Site"
Set-SPContentDatabase -Identity "DemoContentDB" -Status Disabled

Para que no haya duda, voy a comentar el script:

  • Lo primero que hacemos es definir sobre que Aplicación Web (en este caso: http://miintranet) vamos a crear la nueva Colección de Sitio.
  • El siguiente paso, es la creación de una nueva base de datos asignándola a la Aplicación Web, para ello debemos indicar, el nombre de la base de datos, el servidor SQL Server y el objeto SPWebApplication que hemos definido anteriormente.
  • Una vez la base de datos esta lista, creamos la Colección de Sitio, por lo que especificamos varios parámetros obligatorios
  • Por ultimo u no menos importante, si solo queremos que en esta base de datos este esta Colección de Sitio y no se creen las nuevas Colecciones que vayamos creando en esta base de datos, debemos de ponerla offline (en caso de no ser requerido, esta ultima linea se puede comentar).

Referencia de comandos de PowerShellGet-SPWebApplication, New-SPContentDatabase, New-SPSite, Set-SPContentDatabase.