PDF de programación - CompartiMOSS 21

Nº21 septiembre 2014

C O M P A R T IM O S S

Revista especializada en Tecnologías SharePoint

1

COMPARTIMOSS 02
Staff

CompartiMOSS es una pub-
licación
independiente de
distribución libre en forma
electrónica. Las opiniones
aquí expresadas son de es-
tricto orden personal, cada
autor es completamente re-
sponsable de su propio con-
tenido.
DIRECCIÓN GENEAL
• Gustavo Velez
Juan Carlos Gonzalez
•
•
Fabian Imaz
• Alberto Diaz

Contacte con
nosotros

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

BLOGS
http://www.gavd.net
http://geeks.ms/blogs/jcgonzalez
http://blog.siderys.com
http://geeks.ms/blogs/adiazmartin

REDES SOCIALES
Facebook:
http://www.facebook.com/group.
php?gid=128911147140492
LinkedIn:
http://www.linkedin.com/groups/
CompartiMOSS-3776291
Twitter:
@CompartiMOSScom

Nº21 septiembre 2014

C O M P A R T IM O S S

Revista especializada en Tecnologías SharePoint

Contenidos
03 Editorial

Parece que tenemos SharePoint para rato, y hablamos tanto
de la versión On-Premises como de la versión Online.

04. Arquitectura SP distribuida en Azure
10. Diseño Gráfico en SharePoint Foundation 2010 Parte 3
14. Gobernabilidad de Seguridad en SharePoint para la Plata-
forma

17 The Shift Toward Personalized

and Intelligent Collaboration

19. Entrevista a Adrián Díaz
21. Nuevas API’s para desarrolladores en Office 365 - Parte II
27. Diccionarios para el Motor de Búsqueda de SharePoint 2013

34 Publicando un sitio de

SharePoint en Cyberoam

37. Introducción a las App Forms con Acess
42. Administración de SharePoint Online mediante PowerShell
46. Automatizaciones para editar el IIS en SharePoint 2010/2013
52. Creación de Soluciones personalizadas y automatizadas con
Nintex

2

COMPARTIMOSS 03

Editorial

Parece que tenemos SharePoint para rato, y hablamos tanto de la versión On-Premises como de la versión Online. No
tenemos claro cuál es el Roadmap, ni cuando dejará de haber versión On-Premises, pero lo que si podemos asegurar es que
esta revista intentará estar ahí, con artículos de calidad sobre nuestro servidor favorito.

Mientras SharePoint Online se convierte en la opción adecuada, Microsoft y nuestros autores están haciendo muchos
esfuerzos para que nos subamos a Azure e implementemos SharePoint en modo IAAS, y como no podía ser menos, estás
leyendo una editorial que se encuentra a medio camino entre On-Premises y Azure.

Como siempre, los dejamos con un número cargado de artículos impresionantes, con autores habituales y nuevos autores
que esperemos sigan publicando porque sin ellos la revista no llegaría cada tres mesas a vuestros ordenadores. Gracias a
todos y esperamos que la disfruten como nosotros disfrutamos haciéndola.

EL EQUIPO EDITORIAL DE COMPARTIMOSS

El autor destacado del Número 20

Un nuevo número y vuestras lecturas nos aportan salud a la revista y con ellas sabemos que los artícu-
los os aportan beneficios, lo que nos complica la elección del artículo destacado.

Los artículos por capítulos suelen tener éxitos y esta vez tenemos a Miguel Tabera, por su artículo
“Buenas prácticas en infraestructura en SharePoint 2013 Parte II” como el artículo destacado del
número 20. Felicitaciones para Miguel por su continuidad en la revista y por los buenos artículos que
nos escribe, y por supuesto, al resto de autores que aportan su granito de arena en este proyecto.

3

COMPARTIMOSS 04 Arquitectura SP distribuida en Azure

Resumen
Muchas veces nos planteamos el cómo llevar nuestra ar-
quitectura On-Premise a Azure, para aprovechar de forma
conveniente las ventajas de las que disponemos. En este
artículo vamos a ver como montar una arquitectura dis-
tribuida entre varias suscripciones de Azure para disponer
de resistencia antes fallos (Failover) y antes desastres (Dis-
aster Recovery), manteniendo unos costes contenidos
Introducción
Azure es una de las grandes apuestas actuales de Micro-
soft, y de cara al aprovechamiento de los recursos (sobre
todo económicos) de una empresa, presenta grandes ven-
tajas ante una arquitectura On-Premise, especialmente
respecto a la facilidad que nos brinda a la hora de hacer
crecer nuestra arquitectura conforme a los requisitos y/o
disponer de más potencia ante picos puntuales. Del mismo
modo, esto nos permite el disponer de plataformas “pre-
configuradas” como recurso ante caídas de sistemas.

Azure se ha colocado en muy poco tiempo a la altura, si
no por encima, del resto de grandes plataformas cloud, en
cuanto a funcionalidad, y mantiene un ritmo de actualiza-
ciones que permite visualizar en un futuro muy corto fun-
cionalidades que no están disponibles en ninguna de las
actuales, pero al igual que SharePoint en sus inicios es un
entorno que requiere de pequeños “trucos” que nos hagan
más fácil el utilizar sus recursos. El dar a conocer estos tru-
cos y procedimientos es la idea principal de este artículo en
forma de lecciones aprendidas.

Como ejemplo a seguir, vamos a montar una infraestructu-
ra en dos suscripciones. La arquitectura será la mostrada
en el siguiente diagrama:

Servidores

WFE

Servidores
Backend

Servidores

SQL

Availability Group WFE

Servidor

AD

Primario

Servidor

AD

Secundario

Availability Group BES
Servicio SP

Servicio AD

Conexión

VNET-to-VNET

Servicio AD

Availability Group SQL

Servicio SQL

Suscripción 1

Imagen 1.- Diagrama de Arquitectura.

Servidor

WFE

Servidor
Backend

Servicio SP

Servidor

SQL

Servicio SQL

Suscripción 2

En esta arquitectura utilizamos varios de los recursos im-
portantes de Azure:

• Grupos de disponibilidad: Al disponer varios servi-
dores en un mismo grupo de disponibilidad, nos
aseguramos que nunca estén sobre el mismo host
físico, de manera que ante actualizaciones de la
plataforma, nuestros servidores nunca serán re-
botados de forma simultánea.

• Conexiones VNET-to-VNET o Point-to-VNET: Estas
conexiones nos permiten la conexión entre nues-
tra suscripción y nuestra arquitectura On-Premise,
o bien entre diferentes suscripciones

•

Servicios en la nube (Cloud Services): Se considera
el Cloud Service como cada una de las capas (tier)
de una aplicación multicapa, agrupando los servi-
dores que realizan una función definida (WebRole,
WorkerRole. En nuestro ejemplo, SP, SQL y AD).

Por último, para sincronizar nuestras granjas, se esta-
blecerá una sincronización a nivel de SQL con Log Shipping
para permitir que la granja secundaria actúe como Disas-
ter Recovery. Esta configuración tiene la ventaja a nivel de
costes que es posible tener todas las máquinas apagadas
(mientras no sea necesario instalar actualizaciones y/o
ponerla en servicio) exceptuando el SQL. Para el ejemplo
propuesto la granja secundaria esta simplificada, pero en
el ejemplo real sería posible montar una estructura gemela
a la de la granja primaria. El único coste que tendría esta ar-
quitectura sería a nivel de almacenamiento (Storage) y de
tráfico de red a través de la conexión entre suscripciones.
En la práctica sería como tener el doble de servidores en
nuestra arquitectura a un coste prácticamente idéntico.
Como desventaja presenta el hecho de que al instalar ac-
tualizaciones/nuevos desarrollos en nuestra arquitectura
primaria, también hay que realizar la misma acción en la
secundaria, por lo que cobra especial relevancia el uso de
un correcto Plan de Gobierno. Esta desventaja puede ser
mitigada usando scripts de arranque/parada de la granja
secundaria y de despliegue.

Truco: Es posible acelerar nuestro despliegue realizando la gen-
eración de la red, servicios en la nube, grupos de disponibilidad
y máquinas virtuales por medio de scripts PowerShell contra las
conexiones de Azure y ejecutándolos (con los cambios pertinentes)
contra ambas suscripcioines



4

COMPARTIMOSS Prerrequisitos:

• Dos suscripciones a Azure (Suscripcion1 y Suscrip-

cion2).

• Hemos descargado el certificado digital de Azure

para poder acceder por PowerShell.

• Comprobar que desde el panel de suscripciones
podemos cambiarnos de una a otra sin problemas.
• Dibujar nuestra arquitectura (esto no es impre-

scindible, pero ayuda).

Creación del grupo de Afinidad
Un grupo de afinidad se usa para agrupar todos los ser-
vicios en nube juntos, de forma que internamente se dis-
tribuyan en hosts cercanos, maximizando el rendimiento.
Todo el escenario será generado por tanto dentro de tan
solo un servicio de afinidad por subscripción.

Para generar nuestro nuevo grupo, seleccionaremos Set-
tings o configuración, según el idioma seleccionado.
Una vez dentro, seleccionar grupos de afinidad (Affinity
Groups), y pulsar en +Add. Para cada grupo de afinidad, es
necesario dar un nombre específico (en nuestro ejemplo
subscripcion1) y seleccionar una región geográfica. A Es-
paña le corresponde la región Europa Norte.

Esta operación será necesario replicarla en la segunda sub-
scripción.

para sincronizar nuestras granjas, se
establecerá una sincronización a nivel
de SQL con Log Shipping

Creación del almacenamiento
Todas las unidades que tengamos dentro de nuestro ejem-
plo las crearemos dentro de una sola cuenta de alma-
cenamiento, aunque en entornos reales el almacenami-
ento podemos distribuirlo dentro de diferentes cuentas de
almacenamiento. En cada subscripción podemos disponer
de hasta 5 cuentas de almacenamiento, y un máximo de
100 Tb en cada una. Conviene tener en cuenta que estos
límites son revisados muy a menudo por Microsoft, y en
muchos casos no son límites reales. Debido a esto, y si por
la casuística de la implementación que estamos creando
consideramos necesario ampliar alguno de los límites, la
opción más adecuada consiste en ponerse en contacto con
los administradores de Microsoft, pulsando en el menú de
la subscripción, en la opción “Contact Micro