Encriptación de Datos Transparente para SharePoint

SharePoint implementa seguridad a nivel de usuario, si quieres acceder a un fichero pero no tienes los permisos necesarios serás bloqueado y eso es suficiente para la gran mayoría de las empresas, pero...

- ¿Qué pasa si alguien consigue acceder a tu servidor de bases de datos?
+ Podrá fácilmente descargarse la base de datos de contenido, conectarla a uno de sus servidores de SharePoint y tener acceso a todo hasta el branding.
- ¿Qué puedo yo hacer ante esto como desarrollador de SharePoint?
+ Nada.
- ¡Ay, Dios mio! ¡Ay, Dios mio!
+ Tranquilízate muchacho, si quieres encriptar las bases de datos pídeselo al tío de las bases de datos.

Sí, los administradores de base de datos pueden encriptar instancias de SQL usando TDE. Y, aunque parece fácil, estoy contento de no tener que hacerlo yo.

- ¡Pero encriptar todo va a afectar al rendimiento de mi granja!
+ Microsoft cree que solo será entre un 3 y un 5% más lenta.

Puedes conseguir más información sobre este tema aquí y aquí (por ejemplo).

Comprimir Todas las Bases de Datos

No recomendaría hacer esto en un entorno de producción no suena mucho a best practices, pero si tu entorno de desarrollo se está quedando sin espacio en el disco duro creo que es una buena alternativa a comprimir cada base de datos con el ratón una a una…

El código SQL que uso es este:

declare @db varchar(255)declare c cursor for
select name from sys.databases where is_read_only=0 and state=0
  and name not in ('master','model','tempdb','msdb')
open c
fetch c into @db
while @@fetch_status=0
begin
  exec SP_dboption @db,'trunc. log on chkpt.','true'
  DBCC shrinkdatabase (@db)
  fetch next from c into @db
end
close c
deallocate c

(Cogí el código de aquí pero el mío está bien formateado :P)

Auto-Update del SQLServer Express ¡CUIDADO!

Sinceramente espero que esto sólo me haya pasado a mí en todo el mundo, pero me da en la nariz que el mundo es muy grande.

La última actualización (SP3 creo) del SQL Server Express que tengo en un servidor de desarrollo, albergando un SharePoint cómo no..., me ha borrado la instancia OFFICESERVERS con todas sus bases de datos y a cambio me ha creado una prístina instancia nueva llamada SQLEXPRESS.

Si instalaste SharePoint con el método "to p'alante" desconfía de las actualizaciones del SQL Server Express o te puedes encontrar con esto:

Luego dicen que el puenting quema adrenalina... Hombre de Dios, ¡desarrolla un poco para SharePoint y sabrás lo que es el miedo!

Controlar el consumo de memoria del SQL Server

Como habréis notado, en los servidores de pre-producción el SQL Server 2005 agota en un ratito toda la memoria que tengamos. Si apagamos la máquina y le ponemos más RAM el SQL vuelve a comérsela otra vez provocando en nosotros esa desagradable sensación de bucle infinito. Y lo peor es que da igual que la base de datos de contenido ocupe 100MB, el SQL ocupará 1GB antes de que nos demos cuenta.

En estos casos a mi me gusta bajarle un poco los humos y limitarle la cantidad de memoria que puede utilizar, así:

1.- Nos vamos al SQL Server Management Studio y abrimos las propiedades de la instancia en la que estamos trabajando:

2.- Una vez allí vamos a la configuración de Memoria y retocamos los valores de Memoria mínima del server y Memoria máxima del server como mejor corresponda a nuestro server. A mi me gusta poner algo como 128/512, así:

Y ya está, con esto hemos terminado con la vampirización de la memoria de nuestro server por parte del conde SQLServer.

Por supuesto también es posible que en los servidores de producción os convenga que el SQL Server tenga bastante memoria para él, en ese caso podréis poner la combinación que os apetezca, 2048/15360 por ejemplo en un server de 16GB.

Ah otra cosa, los Windows 2003 Server Enterprise con más de 3GB funcionan mejor si editamos el fichero c:\boot.ini y añadimos después de donde pone /fastdetect un /3G quedando el final de la línea

/noexecute=optout /fastdetect /3g

Mantenimiento de bases de datos de SharePoint

Las bases de datos son el corazón de SharePoint y a él también le gusta tener sano su corazoncito.

Para ello, lo que yo suelo recomendar a los administradores es que ejecuten esta serie de comandos una vez al mes por lo menos.

-- Seleccionamos base de datos de contenido
use WSS_Content
GO
-- Comprobamos la consistencia de la base de datos
dbcc checkdb
GO

-- Comprobamos la fragmentación
SELECT * FROM sys.dm_db_index_physical_stats
    (DB_ID(N'WSS_Content'), OBJECT_ID(N'AllDocs'), NULL, NULL , 'DETAILED');
GO

-- Defragmentamos si alguno de los valores supera el 10% (Que va a ser siempre)
ALTER INDEX ALL ON AllDocs
REBUILD WITH (FILLFACTOR = 70, SORT_IN_TEMPDB = ON,
STATISTICS_NORECOMPUTE = ON)
GO

-- Comprobamos la fragmentación para sentirnos orgullosos al ver que se ha corregido
SELECT * FROM sys.dm_db_index_physical_stats
    (DB_ID(N'WSS_Content'), OBJECT_ID(N'AllDocs'), NULL, NULL , 'DETAILED');
GO

-- Y por último "encogemos" la base de datos para compactarla y reducir su peso
DBCC SHRINKDATABASE (0, 20, NOTRUNCATE)
GO

Una pena que no salgan los colores del SQL Query, pero qué se le va a hacer.

Éstas querys están aprobadas por microsoft y se pueden hacer en caliente, obviamente es mejor hacerlas cuando el servidor no está a tope.

Algo que a Microsoft no le gusta nada es que trunquemos el log de la base de datos, pero es que hay veces que para una base de datos de 500 megas tenemos un log de 5 gigas y eso no es mu normal. En estos casos podemos hacer:

BACKUP LOG WSS_Content WITH TRUNCATE_ONLY

Que me perdone Steve Ballmer

Y otra cosa que podemos hacer ya que estamos aqui es curiosear por las bases de datos...

-- Miramos el tamaño del/los sitios (en MB)
SELECT FullUrl, (DiskUsed/(1024*1024)) AS DiskMB
FROM  Sites
ORDER BY Diskused DESC
GO

-- Miramos el TOP10 de bibliotecas (en MB)
SELECT TOP 10 D.DirName, (S.Size/(1024*1024)) AS DiskMB
FROM ALLDOCS as D, AllDocStreams as S
WHERE D.Id=S.Id
ORDER BY S.Size DESC
GO

por ejemplo.

Bueno, me voy a comer.

Jugando con las bases de datos de contenido de SharePoint

¿Hay alguien que no tenga a estas alturas experiencia con atachar y desatachar (¿Asociar y desasociar en castellano?) bases de datos de contenido del SharePoint? Sí hay alguien, de hecho hay mucha gente.
Gracias a esto es fácil hacer backups y restores con las herramientas de SQL, mover las bases de datos a otros servidores, por ejemplo para ampliar granjas, guardar los datos en una cinta y olvidarte de ellos hasta el día que te hagan falta y todos los procesos que se te ocurran con bases de datos con tranquilidad fiabilidad y en cuestión de segundos (quizá más de 60, o más de 86400 segundos si las bases de datos son realmente gordas).
¿Que pasa si la base de datos de contenido de tu SharePoint crece tanto que no cabe en el disco duro que la alberga? pues que nos compramos un disco duro más gordo y la movemos a el.
Por ejemplo, el caso más extremo que se me ocurre es desplegar una base de datos en una granja diferente y ¿quién dijo miedo? es el que intentaré reflejar en este post (lo malo es que en mi casa solo tengo una VM, pero bueno intentaré simularlo lo mejor posible).
Lo primero que necesitamos es tener instalado el SQL Server Management Studio. Si tienes el el SQL Server Express te lo tendrás que descargar de aquí y si instalaste una versión de pago es posible que ya lo tengas instalado o bien que tengas que ir a por tu DVD de instalación del SQL Server e instalar las herramientas.
Lo segundo es que ambas granjas tengan la misma versión, ya puestos la última (SP1). Ya sabes, instalamos WSS 3.0 SP1 primero y luego MOSS 2007 SP1.
Y yo creo que con esto es suficiente, arremangarse niñio.
1.- ¿Cuales son mis bases de datos de contenido?
Antes de empezar a hacer el trasvase tenemos que saber cómo se llaman las bases de datos que queremos trasvasar. Para ello abrimos la administración central y desde allí --> Administración de aplicaciones y luego Bases de datos de contenido.

Como seguramente, por defecto te tomará cualquier aplicación web menos la que tu quieres cambiaremos la aplicación web:

Y una vez que hayamos seleccionado la aplicación web buena podremos ver la lista de bases de datos de contenido que la nutren. En mi caso y muy convenientemente solo es una, la archiconocida por todos WSS_Content.
(Un breve inciso: A mi entender, la única explicación plausible para tener más de una base de datos de contenido por aplicación web es porque, en caso de catástrofe, es más rápido restaurar una base de datos pequeña que una grande, pero NO PASA ABSOLUTAMENTE NADA POR TENER CONTENT DATABASES TAN GRANDES COMO QUERÁIS, Microsoft no pone límite y yo he trabajado con bases de datos de 500GB sin ningún problema de rendimiento.)
Ahora ya sabemos qué queremos copiar, así que vamos con el siguiente paso.
2.- Hacemos backup de nuestra base de datos:
Para ello nos vamos al SQL Server Management Studio y…

Tras pulsar backup debemos configurar la copia en la ventanita que nos sale a continuación. No tiene demasiado misterio, solo hay que recordar que existen los backups diferenciales y que es mejor guardar la copia en un sitio que conozcamos.
(Otro breve inciso: Como habrás imaginado no es la mejor idea del mundo hacer este proceso en el momento de mayor actividad del servidor, aunque se puede hacer en ese momento si te gusta el riesgo)
3.- Nos llevamos la BD al servidor nuevo
Como tenemos una memoria excelente y nos acordamos de dónde hemos guardado el ficherito .bak pues nos vamos allí y lo pasamos al otro server. Dicen las malas lenguas que el SQL Server 2008 comprime los backups, yo no lo he probado todavía, pero si estoy seguro de una cosa el 2005 no lo hace, así que si vas a pasar la base de datos por internet a alguien es una buena idea comprimirla.
4.- Restauramos la base de datos en el servidor nuevo
Algunas veces cuesta un poco de trabajo esto de restaurar las bases de datos.

Si en el servidor donde vais a hacer la restauración de la base de datos ya hay una base de datos con el mismo nombre que la que vais a restaurar y además está en uso el SQL os va a decir que no puede tener acceso exclusivo a ella y va a fallar. Esto es normal, una cosa es hacer el backup en caliente y otra es restaurar una copia de seguridad en caliente.
En ese caso, antes del restore, haremos un detach (Desasociar en castellano) de la base de datos marcando la casilla de Drop Connections (¿Cerrar conexiones?) así:

Si todavía os falla será porque necesita sobreescribir la base de datos antigua, id a Options en la ventana de configuración del restore y dadle permiso al pobrecito.
5.- Configurando la aplicación web para que use nuestra flamante base de datos de contenido:
Igual que en el paso uno, pero esta vez en el servidor nuevo, Abrimos la administración central y desde allí --> Administración de aplicaciones y luego Bases de datos de contenido, después cambiaremos la aplicación web a la que nos convenga.
Una vez hecho esto tendremos que quitar la base de datos de contenido que tiene la aplicación, pulsamos sobre ella y en la ventana que nos sale marcaremos “Quitar base de datos de contenido” luego Aceptar y Aceptar.

Y luego:

(Si la tienes demasiado grande SharePoint se asustará al verla y habrá que metérsela por la puerta trasera) Si la base de datos que estamos adjuntando a nuestra aplicación web es demasiado grande nos dará un error, no pasa nada, para las cosas serias siempre podemos usar el socorrido stsadm el comando sería más o menos:

stsadm -o addcontentdb -url http://erChan -databasename wss_content

6.- Abrimos la web y listo…
Si todo ha ido bien ya podríamos entrar en nuestra aplicación web con su recién atachada base de datos, pero es posible que si has cambiado de entorno el usuario administrador ya no sea el mismo… En este caso tendrías que ir a Administración central –> Administración de aplicaciones –> Directiva de aplicación Web y meter allí como control total al administrador de esta granja.

Y fin, qué post más largo. Ya paso de comentar más nada ¡UF!.
Hay quien dice que este método solo funciona si mientras esperas lees un libro de yoga, pero no creo yo que sea para tanto, de hecho creo que el post en sí ya es un libro de yoga.