¿Para que sirve la carpeta12 hive?: 1) Mapear una Imagen como ícono según tipo de archivo

Luego de varias preguntas sobre la carpeta 12 hive, decidí crear una serie de artículos sobre los archivos XML que se encuentran en ella y como utilizarlos para personalizar nuestra instalación de MOSS 2007, aprovecho para agregar que en la próxima versión de SharePoint Server 2010 es la 14 hive!

Hoy quisiera empezar con un ejemplo sencillo para ilustrar la utilidad y funcionalidad de cada uno de los archivos XML que encontraremos en esta carpeta, por ello he elegido el archivo DOCICON.xml: este archivo es empleado para mapear los tipos de archivos con sus respectivos íconos dentro del Servidor SharePoint.

Para mapear una imagen a un tipo de archivo en particular solo hace falta seguir estos sencillos pasos:

1) Primero ubicaremos al archivo DOCICON.xml en la ruta por defecto de la carpeta 12 hive: <%>Program Files\Common Files\Microsoft Shared\web server extensions\12

2) Editar el archivo DOCICON.xml en el block de notas o cualquier otro editor de texto sencillo, en la sección "ByExtension " crearemos una nueva entrada para mapear una imagen como ícono de los archivos con extensión ".pdf", con una línea de código similar a esta:

<Mapping Key="pdf" Value="mi_icono_pdf.gif"/>

3) Finalmente debemos dejar disponible la imagen mapeada "mi_icono_pdf.gif", copiándola en la carpeta: Program Files\Common Files\Microsoft Shared\web server extensions\12\Template\Images

IMPORTANTE: La imagen que se emplee como ícono debe ser de 16x16 pixeles.

Espero que este ejemplo les sea de utilidad. En futuras entregas estaré conversándoles sobre los otros archivos de la carpeta 12 hive, hasta entonces!

Control RIBBON de SharePoint Services 14 y SharePoint Server 2010: Agregar Botones

La próxima versión de SharePoint nos trae impresionantes y nuevas características entre ellas el Ribbon, que ha sido incluido en la intefaz de usuario tanto para Windows SharePoint Services 14 como de Microsoft SharePoint Server 2010. Este vistoso control puede ser extendido mediante la infraestructura de características o "Features", en este artículo explicaré como agregar un botón dentro del Ribbon.

Antes que nada debo comentar que la arquitectura del Ribbon tiene como objetos de primer nivel "Tabs" los cuales aparecen en el tope de la página de SharePoint. Cada TAB tiene a su vez conjuntos de "Grupos", los cuales pueden contener una colección de controles, entre ellos BOTONES.

Para desplegar una nueva característica del Ribbon es necesario crear e instalar un archivo XML donde se define el alcance y la información respecto de la característica, este archivo deberá ser nombrado como: "Feature.xml", un ejemplo de un archivo Feature.xml seria:

<?xml version="1.0" encoding="utf-8" ?>
<Feature Id="FeatureId" Title="Name of the Feature" Description="Descripcion de la caracteristica" Version="1.0.0.0" Scope="Web" xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="manifest.xml" />
</ElementManifests>
</Feature>

Como podemos notar cada archivo Feature.xml va a acompañado respectivamente de un archivo manifest.xml, el cual especifica la creación del control dentro del TAB y grupo que se especifiquen.

Para instalar la característica ejecutamos el siguiente comando en el Windows PowerShell:

Install-SPFeature FeatureId

Enable-SPFeature FeatureId -Url http://server/site/subsite

Donde el "FeatureId" será el ID que le asignemos a la característica. Luego de instalar una nueva característica mediante Windows PowerShell debemos reiniciar el IIS ejecutando la siguiente línea en la ventana de comandos:

iisreset

AGREGAR UN BOTON AL RIBBON

Para agregar un botón al Ribbon:

1) Crear una carpeta llamada "AgregarBoton" en la ruta: %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES.

2) En esta ubicación creamos el archivo featurexml como lo hemos descrito arriba.

3) Creamos el archivo XML manifest.xml siguiendo esta guía:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction Id="Ribbon.Library.Actions.AddAButton" Location="ViewToolbar" RegistrationId="101" RegistrationType="List" Title="Agrega un boton al Ribbon">
<CommandUIExtension>
<CommandUIDefinitions>
<CommandUIDefinition Location="Ribbon.Library.Actions.Controls._children">
<Button Id="Ribbon.Library.Actions.NewRibbonButton"Command="NewRibbonButtonCommand" Image16by16="/_layouts/images/FILMSTRP.GIF" Image32by32="/_layouts/images/PPEOPLE.GIF" LabelText="New Button" TemplateAlias="o2" />
</CommandUIDefinition>
</CommandUIDefinitions>
<CommandUIHandlers>
<CommandUIHandler
Command="NewRibbonButtonCommand"
CommandScript="javascript:alert('este es un nuevo botón!');" />
</CommandUIHandlers>
</CommandUIExtension>
</CustomAction>
</Elements>

Este XML agrega un botón en el TAB de la librería en el grupo "Actions", luego de personalizarlo con nuestros datos lo guardamos como manifest.xml.

4) Instalamos la nueva característica usando Windows PowerShell como lo indicamos al principio.

5) Para probar la nueva característica navegamos hasta la librería de documentos en el sitio o sub-sitio, hacemos clic en el TAB "Library", buscamos en el grupo "Actions" y hacemos clic en el botón "New Button".

Este articulo esta basado en la documentación liberada hace un par de meses como: “SharePoint Products and Technologies: 2010 (Technical Preview) Developer Documentation” y la misma puede ser descargada junto con un vista previa del SDK para esta nueva versión SharePoint Services 14 desde este enlace de Microsoft: http://www.microsoft.com/downloads/thankyou.aspx?familyId=94afe886-3b20-4bc9-9a0d-acd8cd232c24&displayLang=en

STSADM Import/Export: 7 Cosas que Saber al Migrar Sitios o Colecciones de Sitios

1) WSS 3.0 a WSS 3.0, WSS 3.0 a MOSS 2007 o MOSS 2007 a MOSS 2007:
Mediante las operaciones “Import” y “Export” de la herramienta STSADM podemos exportar sitios o colecciones de sitios desde una instalación de WSS 3.0 a otra instalación de WSS 3.0 ubicada en otro servidor, dentro o fuera del mismo dominio. También podemos mediante estas operaciones importar sitios o colecciones de sitios desde una instalación de WSS 3.0 a una instalación de MOSS 2007. Pero, no es viable importar un sitio o una colección de sitios que hayan sido exportados de un MOSS 2007 a una instalación de WSS 3.0. En primer lugar esto sería un downgrade importante y esto se debe a que aunque MOSS 2007 usa los mismos servicios de WSS 3.0 posee muchas características que no estarán presentes en un WSS 3.0. Hago la salvedad de que en alguna rara ocasión donde exista una colección de sitios de MOSS 2007 creada con una plantilla básica y donde no se haya aprovechado de ninguna manera las características de MOSS 2007 podría existir la posibilidad de que dicha migración a WSS 3.0 funcione.

2) Service Packs:
Cuando empleemos las operaciones “Export “ e “Import” de la herramienta STSADM para migrar sitios o colecciones de sitios de un servidor A a otro B, es importante validar los mismos SP’s instalados en el servidor A estén instalados también en el servidor B, de lo contrario al momento de ejecutar la operación “Import” se arrojaran errores como el conocido: "FATAL ERROR-AllowAutomaticASPXPageIndexing".

3) Language Packs:
Al migrar contenido de un servidor a otro también debemos observar los que paquetes de idiomas instalados en el servidor de origen también lo estén en el servidor de destino, incluyendo los “service packs” de los mismos, bien sean: WSS 3.0 Language Pack SP1, WSS 3.0 Language Pack SP2 o MOSS 2007 Language Pack SP1, MOSS 2007 Language Pack SP2.

4) Opción – nofilecompression:
Cuando trabajemos con colecciones de sitios muy extensas (> 1Gb) seguramente se presentaran fallas al exportar en archivos comprimidos o importar desde archivos comprimidos, es por ello que en estos casos se deberán exportar los sitios a un directorio usando la opción – nofilecompression, de igual manera al importar desde estos sitios en el servidor de destino.

5) Poco espacio en Disco:
La herramienta STSADM utiliza la unidad C: del sistema para crear los archivos temporales que se exportaran, típicamente ubica estos temporales en los directorios definidos en las variables de entorno de sistema “TEMP” y “TMP”, en ocasiones nuestro servidor SharePoint queda con poco espacio en la unidad del sistema C: y esto nos imposibilita realizar la operación “Export” mediante la herramienta STSADM por que nos arrojará el error “There is not enough space on the disk”, el remedio es sencillo: debemos “mover” la variable de entorno del sistema “TEMP” a otra unidad con mayor capacidad libre que el tamaño de la colección de sitios que deseamos exportar.

6) “RUN AS…”:
Cuando ejecutamos las operaciones “Import” o “Export” (y la mayoría de las demás operaciones de STSADM) requerimos hacerlo mediante una cuenta de dominio con privilegios de administrador de granja o administrador de la colección de sitios para que estas operaciones corran sin inconvenientes de permisos. Para ello siempre ejecutaremos nuestra consola de comandos “cmd” como administrador.

7) Usuarios entre Dominios:
Al migrar colecciones de sitios entre servidores en diferentes dominios debemos tener presente que si queremos conservar la seguridad de usuarios y grupos en el nuevo dominio debemos ejecutar las operaciones “Export” e “Import” siempre con el parámetro: “-includeusersecurity”, esto nos asegurara que junto con el contenido se migren los usuarios, grupos y permisos. Ahora bien, ¿que pasa los usuarios del viejo dominio en el nuevo dominio?, bueno hay que realizar otra operación para que los usuarios “traídos” del anterior dominio funcionen en el nuevo, para ello emplearemos la operación “migrateuser” de STSADM, mediante esta operación podemos asignarle una cuenta de usuario en el nuevo dominio (previamente preparada en el directorio activo) a cada uno de nuestros usuarios del anterior dominio. Esta tarea tiene implícito un reto: que debemos hacer esto con cada uno de los usuarios migrados, lo cual puede resultar agotador si hablamos de decenas o cientos de usuarios, para ello lo indicado es crear un BATCH para que itere cada usuario y de forma automatizada vaya realizando la migración.

Establecer URL Personalizado a Nuestro Sitio Web de SharePoint Mediante HOST HEADERS de IIS 7 y “Alternate Access Mappings”

Cuando publicamos un sitio web de SharePoint dentro de la red corporativa de una organización siempre resulta mejor proveer a nuestros usuarios de un URL que les resulte familiar y fácil de recordar en vez de utilizar un URL con el nombre del servidor como http://servidorsp01, por ejemplo: http://intranet o simplemente http://sharepoint , ¿como logramos este efecto?

Primero:

Crearemos un Binding en IIS 7, para ello abrimos el Internet Information Services (IIS) Manager, expandimos el nodo de sitios y ubicamos el sitios web que deseamos personalizar, luego haciendo clic con el botón derecho elegimos “Edit Bindings” del menú contextual, como se muestra en la siguiente imagen:

Alli seleccionamos el Binding que queremos editar y hacemos clic en el botón “Edit”, surgirá una ventana como la siguiente:

En esta ventana asignamos en el campo “Host name” el nombre personalizado que queremos dal al URL del sitio Web. Con esto terminamos con el II7. mas informacion sobre host headers en IIS 7 bindinds en http://technet.microsoft.com/en-us/library/cc753195(WS.10).aspx




Segundo:

En la Administración Central de SharePoint en la pestaña “Operations” dentro del reglón “Global Configuration” seleccionamos “Alternate Access mappings”:

Alli podremos observar los URL internos activos la zona a la cual pertenecen (internet, intranet, extranet o personalizada) y el URL público o real:

Luego seleccionamos “add internal URLs” lo cual desplegará la siguiente pantalla:

Una vez aquí seleccionamos la colección de sitios que deseamos mapear y agregamos el URL interno que nos interesa (por ejemplo: http://intranet ) en el campo “URL, protocol, host and port” y seleccionamos la zona a la cual asignaremos esta URL, en el caso que les planteo en este articulo seria la zona “intranet”, pero también es posible definir URL personalizados que mapeen nuestros sitios Web en internet, la diferencia radicara en donde estén definido el DOMAIN NAME de nuestro servidor Web, si es en un DNS interno de la organización o si es un DNS de internet.

Finalmente:

Como hemos definido un URL personalizado el mismo debería poder ser resuelto por el DNS interno de la organización para ello definiremos en nuestro DNS un alias (CName), ello lo hacemos en la consola de administración de DNS, seleccionando el nodo de la zona donde esta el servidor Web de SharePoint y haciendo clic con el botón derecho veremos un menú desplegado con la opción “New Alias(CName)” si la seleccionamos veremos la siguiente ventana:

En el campo “Alias name” ingresamos el mismo nombre que hemos definido en los pasos anteriores (por ejemplo: intranet) y en el campo “Fully qualified domain name” ingresaremos el nombre completo del servidor, finalmente hacemos clic en “Ok” y listo!.
Es probable que tarde un poco en propagarse esta regla del DNS por todo el dominio de la organización pero una vez propagada nuestros usuarios podrán acceder a nuestro sitio mediante un URL familiar y fácil de recordar.

Migrando una Colección de Sitios de WSS 3.0 a una de MOSS 2007 mediante STSADM

Siempre resulta un alivio contar con una herramienta de línea de comandos como STSADM, sobre todo cuando queremos realizar tareas administrativas, como por ejemplo: Migrar una Colección de Sitios de Windows SharePoint Services 3.0 en un servidor a una nueva Colección de Sitios de Microsoft Office SharePoint Server 2007 en otro servidor. A menos que cuenten con un arsenal de herramientas de terceros como AvePoint, Metalogix, Quest, Tzunami esto podría resultar un dolor de cabeza sino estamos bien enterados de cómo enfrentar este reto.
Existen varios enfoques para este reto pero en este articulo solo me referire al empleo de la
Herramienta "build-in" de línea de comandos de SharePoint STSADM.
Lo resumiré en 3 pasos sencillos y más adelante en nuevos artículos iré detallando cada uno y trataré de de adelantarme a los posibles errores que pudieran surgir:

1) En el servidor de origen con WSS 3.0 y la colección de sitios que deseamos migrar, abrimos nuestra ventana de consola de comandos "cmd" del la barra de inicio, ubicamos el contexto de la misma en el directorio: "c:\program files\common files\microsoft shared\web extensions\12\bin\" o el equivalente del ambiente de su instalación particular de WSS 3.0, allí ejecutamos la siguiente linea:

c:\%12hive%\bin> stsadm -o export –url http:///sites// –filename .cab -includeusersecurity

Explico un poco: la operación "export" se encargará de exportar todo el contenido de la colección de sitios que especifiquemos en nuestro comando en el parámetro "url", salvando todos estos datos en un archivo especificado en el parámetro "filename", seguramente desearemos migrar también los usuarios, grupos y permisos para ello incluimos el parámetro "includeusersecurity", pues bien esto será suficiente para colecciones de sitios no muy grandes (<1GB) y nos generará un archivo comprimido con extensión .cab.

2) Luego copiamos el archivo con los datos comprimidos (.cab) a nuestro otro servidor MOSS 2007, allí y también mediante una ventana de consola de comandos "cmd", y contextualizada en el mismo directorio que en el paso 1, procedemos a ejecutar el siguiente comando:

c:\%12hive%\bin> stsadm -o createsite –url http:///sites/ –ownerlogin \ -owneremail

Explico esto un poco: mediante este comando y los parámetros indicados crearemos una nueva colección de sitios de SharePoint que nos servirá como lugar donde importaremos los datos migrados de la antigua colección de sitios de WSS 3.0, la operación "createsite" nos creará una nueva colección de sitios especificado dentro de la aplicación Web con el parámetro "url", seguramente vamos a necesitar un propietario de la colección de sitios y este lo asignamos mediante el parámetro "ownerlogin" y "ownermail".

3) Finalmente y una vez que tenemos nuestra nueva colección de sitios en el servidor MOSS 2007 ejecutaremos la siguiente línea en la misma ventana de consola de comandos:

c:\%12hive%\bin> stsadm -o import –url http:///sites/ –filename .cab -includeusersecurity

Explicare un poco ésta línea este también: mediante la operación "import" descomprimiremos los datos de la colección de sitios de WSS 3.0 incluidos en el archivo (.cab) que definimos en el parámetro "filename" y los ubicaremos en la nueva colección de sitios de MOSS 2007 en el url que definimos en el paso 2 y que volvemos a copiar aquí en el parámetro "url", además nos aseguraremos de restaurar toda la seguridad de usuarios, grupos y permisos con el parámetro "includeusersecurity". Listo solo basta esperar que el comando termine de ejecutar para acceder a nuestro sitio raiz de la nueva colección de sitios migrada a MOSS 2007.

IMPORTANTE: Aunque en la realidad la teoría que acabo de ofrecer no difiere esencialmente mucho, deben saber que no todo lo que brilla es oro y que todo operación tiene sus riesgos y sus mitigantes. en próximas entregas estaré profundizando en estos riesgos y las estrategias para mitigarlos, así como también algunos tips útiles que les servirán para salir de los muy probables issues que encontraran durante una migración de sitios de sharepoint de servidores a servidores, incluyendo issues de idiomas, de dominios diferentes, de grandes tamaños de las colecciones de sitios, de privilegios necesarios para realizar las operaciones en cada servidor, de cuando usar archivos .cab y cuando no usar compresión y de los problemas de poco espacio en disco en el servidor de origen y como atacar cada uno de ellos.