Además del anuncio del soporte de la plataforma SharePoint SP1 en Hyper-V y otros vendors, el team de SharePoint ha anunciado también el soporte de implementaciones MOSS SP1 (y WSS SP1) empleando SQL Server 2008 (http://blogs.msdn.com/sharepoint/archive/2008/08/15/sql-server-2008-support-for-sharepoint-products-and-technologies.aspx).

Es importante resaltar que si bien SQL Server 2008 trae mejoras en tanto a disponibilidad (), seguridad (http://technet.microsoft.com/en-us/library/cc645578.aspx), cifrado de datos (TDE - Transparent Data Encryption - http://msdn.microsoft.com/en-us/library/cc278098.aspx), y administración en general (http://technet.microsoft.com/en-us/library/cc645579(SQL.100).aspx), muchos de estas nuevas características realmente impactarían negativamente en la performance de SharePoint. Obviamente, cifrar la base de datos de configuración no suena muy bien, cierto?

Mejor lee un poco lo que Joel Oleson opina al respecto: http://www.sharepointjoel.com/Lists/Posts/Post.aspx?List=0cd1a63d%2D183c%2D4fc2%2D8320%2Dba5369008acb&ID=73

-.M.-

Ahora MOSS 2007 SP1 (y WSS SP1) están soportados para ser instalados en entornos en producción empleando Hyper-V de Windows Server 2008, además de otras plataformas de virtualización.

El anuncio formal del team de SharePoint está aquí: http://blogs.msdn.com/sharepoint/archive/2008/08/18/update-on-virtualization-support-for-sharepoint-products-and-technologies.aspx, y es parte de un anuncio mucho mayor por parte de Microsoft que incluye productos como SQL Server, Exchange Server, entre otros (http://www.microsoft.com/presspass/press/2008/aug08/08-19EasyPathPR.mspx).

Lo mas resaltante es notar que la política de virtualización de Microsoft para MOSS y otros servidores ahora incluye también a vendors de virtualización no-Microsoft (Cisco Systems, Inc., Citrix Systems, Inc., Novell, Inc., Sun Microsystems, Unisys Corp., Virtual Iron Software, VMware, Inc.), si es que son homologados en su programa Server Virtualization Validation Program (SVVP - http://www.windowsservercatalog.com/svvp/).

-.M.-

Ustedes estarán ya al tanto del Infrastructure Update de WSS y MOSS (http://technet.microsoft.com/en-us/library/cc718729.aspx -Download WSS: http://www.microsoft.com/downloads/details.aspx?FamilyID=256CE3C3-6A42-4953-8E1B-E0BF27FD465B&displaylang=en, Download MOSS: http://www.microsoft.com/downloads/details.aspx?familyid=3811C371-0E83-47C8-976B-0B7F26A3B3C4&displaylang=en).

Presenta muchas mejoras pero acorde con información publicada por Joel Oleson (http://www.sharepointjoel.com/Lists/Posts/Post.aspx?List=0cd1a63d%2D183c%2D4fc2%2D8320%2Dba5369008acb&ID=70), es mejor NO INSTALAR EL UPDATE EN GRANJAS QUE EMPLEEN AAM (alterate access mappings).

Aparentemente existe un bug en el Update que afecta a las implementaciones de MOSS empleando AAM, de modo que solo el internal URL aparece. Según el post de Joel, esto no ocurriría en granjas que emplean AAM + ISA Server, aunque de todas maneras es recomendable no instalar TODAVIA el update si en tu implementación empleas AAM.

 Comentarios?

--.M.-

Hoy el SharePoint Tem ha anunciado algunas caracteristicas que vienen con el futuro lanzamiento del SP1 para MOSS y WSS 3 (http://blogs.msdn.com/sharepoint/archive/2007/11/29/preview-into-wss-3-0-sp1-and-sharepoint-server-2007-sp1.aspx)

 Si no has leido el articulo, aqui van unos avances:

• Soporte para WebParts desarrollados con AJAX Control Toolkit para ASP.NET y AJAX Extensions.
• Soporte para Windows Server 2008: todos los roles, excepto Core Server, soportarán MOSS SP1 y WSS SP1. Además, ya no es requerida la instalación del rol previo de WSS en Windows Server 2008 para la instalación de MOSS. Ahora se realiza tal cual lo hiciste en Windows Server 2003.
• Nuevas opciones para STSADM:
• mergecontentdbs: para unir o separar colecciones de sitios en las bases de datos de contenido
• renamesite: para renombrar colecciones de sitios
• etc!
• Varios Hot-fixes: por supuesto, en SP1 se incluyen muchos hot-fixes lanzados hasta el momento previo al RTM de SP1 (mas de 60)

-.M.-

HAZ CLIC EN EL TITULO DEL ARTICULO PARA VERLO MEJOR (SIN CORTES) 

En el artículo anterior escribí acerca de cómo construir un Master Page que funcione con MOSS. También les conté sobre los controles y algunos tips, además del Minimal Master Page y de mi xMP. Faltó, por supuesto, un gran detalle: los estilos visuales, o archivos CSS.

Antes de empezar

Todo lo que escribiré respecto a CSS es, casi siempre, dentro del contexto de MOSS (o SharePoint) en todo caso. No soy un experto en diseño web, ni tampoco en CSS. Lo que voy a escribir es lo que he aprendido desde MOSS Beta 2 y que me ha servido hasta el dia de hoy para construir sitios web MOSS altamente personalizados, visualmente hablando.

Background teorico (y un poquito de historia)

Hace mucho tiempo atrás, en una galaxia muy lejana… las páginas web servían para mostrar básicamente texto y algunas imágenes. Las personas recibían información tal como noticias, artículos, o informes mediante este nuevo medio que Tim Berners Lee llamó la “World Wide Web” o WWW. Como la tecnología era nueva, casi todos éramos felices con lo que había. Estas páginas se escribían con un lenguaje llamado HTML que básicamente define elementos mostrados en la página de acuerdo al orden en que son llamados a la hora de escribirla (o “programarla”), además de poder definir el color y un poco los estilos visuales de estos elementos, a decir: color de textos, tablas filas, columnas, fondo, imagen, etc.

Esto funcionaba bien para el uso inicial de la web: páginas simples orientadas en su mayoría al texto. Pero al popularizarse la tecnología, se empezó a elaborar cosas un poco mas complejas: animaciones, layouts avanzados asistidos por diseñadores, etc. HTML fue evolucionando para dar soporte a mas elementos, (“etiquetas”), y los navegadores los acompañaron en esto.

Luego, la web se convirtió en un medio de comunicación masivo, visitado por millones de personas diariamente, que mostraba contenidos dinámicos, dando soporte ya no solo a páginas, sino a aplicaciones, portales, extranets… el término “web” se popularizó y pasó a ser una manera más de poder extender una aplicación completa hacia el usuario, dándole acceso remoto desde prácticamente cualquier lugar, con tan sólo un navegador web. Aplicaciones corporativas, aplicaciones de terminales remotos, aplicaciones de trámites en línea (formularios), aplicaciones de audio/video… en fin.

Todas estas aplicaciones y páginas dinámicas eran (y son actualmente) generadas por un servidor, aplicando lógica visual y funcional mediante la utilización de una serie de lenguajes de programación, cuyo resultado de procesamiento es finalmente enviado hacia el navegador del usuario en formato HTML. Visual y funcionalmente este contenido mostrado es espectacular, pero es un spaghetti a la hora de mantener/editar/depurar: lo que define la estructura (tal como una etiqueta de columna) tenía codificada además del contenido en sí, a sus atributos visuales, como por ejemplo, color de fondo, de texto, o ancho total (quienes hayan visto ASP clásico o JSP sabrán a lo que me refiero). Si un diseñador web quería modificar un elemento netamente visual de la página, tenía que entrar necesariamente a trabajar junto con el código que define la estructura, contenido y formato, lo que ciertamente ponía en riesgo la integridad de la página, y hasta la funcionalidad: una etiqueta pasada por alto, un borrón de más, y fue. Funcionalidad rota, contenido inservible. Forma y fondo juntos hasta la muerte. Carpe noctem web designer!!

CSS (Cascading Style Sheets)

Afortunadamente a alguien se le ocurrió la sabia idea de separar forma de fondo. Regresar al HTML para definir contenido, pero poner en otra capa el tema visual. De este modo, los autores de contenido tendrían que encargarse solamente de crear contenido, y los diseñadores web se encargarían de definir cómo luce, donde va, y cómo va ordenado este contenido. Esta capa extra se conoce como Hoja de Estilos en Cascada, o Cascading Style Sheet (CSS).

Veamos cómo se definían los estilos visuales en una página web de los primeros tiempos

Verás que ese elegante fondo verde está definido como color de la celda, directamente en el mismo archivo HTML. Si quisiera hacer un cambio de color, tendría que editar el archivo HTML, pudiendo accidentalmente alterar el contenido

Un archivo CSS es un archivo de texto plano que tiene definidos ciertos formatos visuales agrupados, por ejemplo, uno de estos grupos (formalmente llamado “clase”) podría llamarse “.fondo-verde” y especificar un tipo de fuente determinado (Arial?, Verdana?, Courier?, cual te provoca?), su tamaño (10pt?, 12pt?), su color, su posición relativa al borde de la página, o relativa a la etiqueta HTML próxima, su visibilidad, su borde, sus márgenes… en fin. De modo que en lugar de editar el estilo visual en el mismo documento HTML, asocio este archivo CSS al archivo HTML, y además asocio las etiquetas HTML que yo desee con los estilos definidos en el CSS, así

NOTA: esta no es la única manera de incluir estilos en un documento HTML. Existen varias maneras de hacerlo, pero creo que de este modo se produce una separación clara entre las capas HTML y CSS

Te das cuenta que conseguimos el mismo resultado? Pero hemos separado las capas HTML y la capa de diseño (que define, entre otras cosas, el color). Y la magia la hace el famoso archivo llamado en este caso estilos.css, que tiene el siguiente código:

Este código tiene instrucciones CSS. Si buscas en internet podrás encontrar información de cómo utilizarlo.

Entonces es claro que ahora un diseñador web puede dedicarse a modificar el código CSS (que está en el archivo CSS), mientras que los editores de contenido o de formato se pueden encargar de lo que les corresponda. Además, si aprendes a utilizar CSS, podrás lograr efectos espectaculares, que simplemente no se podían lograr (al menos tan “elegantemente”) con el formato visual limitado del HTML.

Para cerrar este punto, puedes asociar múltiples hojas de estilos a un documento HTML, de modo que si un estilo no se encuentra en una, se buscará en otra, y así sucesivamente. El orden en que son referenciadas las hojas de estilos define la precedencia de un estilo sobre otro que se encuentre definido con el mismo nombre en otra hoja de estilos. El último estilo referenciado será el que sea aplicado efectivamente de modo incremental, tomando un comportamiento de “cascada” (de ahí el nombrecito).

OK, y SharePoint?

Que crees… SharePoint utiliza CSS en sus páginas. En el post anterior a este expliqué cómo están formadas las páginas en SharePoint, y cómo crear un propio Master Page… pero sin estilos visuales!! Ahora veremos cómo darle vida a ese Master Page via CSS. Hang on!!

Primero, aterricemos en MOSS. Lo que pasa es que no es tan fácil el manejo de Master Pages en WSS, al menos fuera de la caja, y todo este tema de branding se da mucho mas fuerte en MOSS que en WSS, así que acá nos quedamos –aunque, ciertamente, algunas partes de lo que viene a continuación puede aplicar también a WSS, pero no haré distinciones en ello.

Los Master Pages que trae MOSS utilizan sus propios CSS, en algunos casos un master page puede utilizar no solo uno, sino varios CSS. En el caso del Master Page que MOSS utiliza por defecto en los sitios de colaboración (default.master), MOSS emplea un archivo en particular y MUY importante llamado CORE.CSS

CORE.CSS

CORE.CSS es un archivo CSS que se encuentra en el sistema de archivos de los servidores Web Front-End de MOSS, en la ruta C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\<lcid>\STYLES\CORE.CSS (donde lcid es el código regional: 3082 si los binarios son en español, 1033 si están en inglés, etc.), el cual es utilizado como base para casi todos los estilos visuales de MOSS, tanto para las páginas de vista al usuario final, páginas administrativas, páginas de listas, de vistas de formulario, etc. Puedes encontrar una guía de las clases CSS que afectan a determinadas zonas del Master Page por defecto de MOSS en este post. Además, si tu inicias una modificación (o creación) de Master Page a partir de default.master, y asocias tu propio archivo CSS a este nuevo Master Page, y no modificas *la totalidad* de estilos, entonces el resto serán aplicados a partir de CORE.CSS. Es decir, primero se aplicarán TUS estilos y luego los de CORE.CSS (cascada, recuerdas?). En conclusión: CORE.CSS es un archivo crítico en MOSS, y no debe ser removido ni modificado, ya que esto no es soportado ni tampoco recomendado.

Incluir archivos CSS adicionales

Entonces, si no debemos tocar CORE.CSS, tenemos dos opciones:

- Hacer una copia de éste, ej: CORE-COPY.CSS, y modificarlo, asociándolo por supuesto al Master Page deseado, o de otro modo

- Incluir un archivo CSS totalmente distinto, empleando clases propias y alejarnos de las clases que trae MOSS por defecto.

Hacer una copia de CORE.CSS

Esto es bastante simple. Entra a la carpeta donde se encuentra CORE.CSS y realiza una copia del archivo, en la misma carpeta.

Asumiendo que esta nueva copia se llama CORE-COPY.CSS, debes asociarla a tu Master Page del siguiente modo:

1. Abre tu sitio SharePoint desde SharePoint Designer

2. Ve a la carpeta _catalogs/masterpage (esta es la ruta virtual expuesta desde la base de datos para el Master Page Gallery)

3. Abre algún Master Page, desprotegiéndolo (check-out) –puedes abrir default.master para empezar

4. En el código, ubica el control <SharePoint:CssLink runat="server"/> y posiciona el mouse ahí.

5. En el cuadro de propiedades, escribe el URL que referencia a CORE-COPY.CSS, así

NOTA: esta ruta “virtual” en realidad referencia al archivo CORE-COPY.CSS almacenado en C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\<lcid>\STYLES\CORE-COPY.CSS. Es de este modo como se especifica la relación de un CSS alojado en disco con las páginas de MOSS.

6. Si cambias a la vista de diseño, verás que se refresca la pantalla, y si verificas el código, verás que la etiqueta mencionada en el paso 4, ahora luce así:

<SharePoint:CssLink runat="server" DefaultUrl="/_layouts/3082/styles/CORE-COPY.CSS"/>

7. Guarda los cambios, y aprueba el Master Page –hey! No modifiques default.master!! guarda una copia, como MyDefault.master o algo así.

8. Ahora aplica tu Master Page al sitio.

Notarás que el sitio luce exactamente igual, y esto es lógico, ya que CORE-COPY.CSS hasta este momento no ha sido modificado, y es exacto a CORE.CSS.

Lo bueno de esto es que ahora podrás modificar CORE-COPY.CSS desde el disco. Yo recomiendo hacerlo con SharePoint Designer ya que tiene una especie de IntelliSense para CSS, muy útil. De este modo, tu personalización se verá reflejada inmediatamente al salvar los cambios en CORE-COPY.CSS

Si ya abriste CORE-COPY.CSS y te diste cuenta que son mas de 1400 líneas y no entiendes nada, este post te dirá qué significa cada estilo. Heather Solomon también ha publicado una excelente guía de los estilos de CORE.CSS

Ventajas:

- Debugging rápido de estilos. Los cambios son reflejados automáticamente en el sitio.

- La implementación es soportada –recuerda que NO es soportado alterar CORE.CSS

Desventajas:

- Debes desplegar el archivo CSS en todos y cada uno de los servidores Web Front-End de la implementación

- En un escenario como este, mantener la consistencia entre versiones de un archivo alojado en disco de muchos servidores Web de Front-End puede resultar un problema

- El backup del archivo es manual y no lo incluye ninguna herramienta de backup/restore de MOSS

En conclusión, utilizar un CSS de este modo es el modo mas práctico para probar tus propios estilos rápidamente, aunque una vez terminadas las pruebas/debugging es recomendado publicarlo NO en el sistema de archivos, sino almacenarlo en la base de datos de contenido, del siguiente modo:

1. Ingresa via web a la Biblioteca de Estilos de la colección de sitios donde está tu Master Page personalizado (http://tu_sitio_moss/Style%20Library/Forms/AllItems.aspx)

2. Carga el archivo CSS personalizado –en este caso CORE-COPY.CSS. Realiza todo el proceso de protección (check-in), aprobación y publicación.

3. Ahora nuevamente abre tu sitio SharePoint desde SharePoint Designer.

4. Ve a la carpeta _catalogs/masterpage (el Master Page Gallery donde está su Master Page)

5. Abre tu Master Page (el mismo que modificaste antes para incluir tu CSS –dale chek-out y toda la historia)

6. Ubica la línea de

<SharePoint:CssLink runat="server" DefaultUrl="/_layouts/3082/styles/CORE-COPY.CSS"/>

7. Reemplázala por la siguiente:

<SharePoint:CssRegistration name="<% $SPUrl:~SiteCollection/Style Library/CORE-COPY.CSS%>" runat="server"/>

8. Salva nuevamente los cambios y aprueba tu Master Page. Notarás que la página permanece intacta con relación a los cambios que tu hayas realizado en CORE-COPY.CSS

Lo que has hecho, es utilizar otro control que te permite referenciar a CORE-COPY.CSS ya no desde el disco, sino desde la Biblioteca de Estilos de la colección de sitios, lo que quiere decir, desde la base de datos.

Ventajas:

- Despliegue unificado. Sólo necesitas realizar esto una vez. No es necesario hacerlo varias veces en caso tengas varios servidores Web de Front-End.

- El archivo está en la base de datos, de modo que está incluido en el backup/restore de una colección de sitios, mediante las diversas herramientas de MOSS.

- El control referencia a la Biblioteca de Estilos de un modo relativo, no mediante una ruta absoluta, de modo que si tu migras esta colección de sitios a otro servidor, o a una ruta distinta de la original mediante una operación de backup/restore, los estilos visuales permanecerán aplicados (en tanto el backup/restore sea de todo el contenido de toda la colección de sitios).

Desventajas:

- El debugging es lento. En caso necesites variar estilos, deberás modificar el archivo realizando todo el proceso de publicación (check-out, modificación, check-in, aprobación, publicación)

Yo diría que esta es la única desventaja, por otro lado me parece la estrategia mas recomendada para aplicar estilos visuales.

Por otro lado, esta desventaja puede ser eliminada, ya que en la misma página donde elegimos un Master Page (http://tu_sitio_moss/_Layouts/ChangeSiteMasterPage.aspx) podemos asociar un CSS alternativo, que se aplicará primero que el CSS que has asociado a tu Master Page.

Aunque este CSS también deberá estar almacenado (idealmente) en la Biblioteca de Estilos, por lo menos puedes tocarlo y no meterte con los estilos que ya definiste, por ejemplo, en CORE-COPY.CSS.

De este modo podrás poner en este CSS alternativo las mismas clases que quisieras modificar de CORE-COPY.CSS, y los cambios que realices se aplicarán, ya que el orden de la cascada es el siguiente:

Se entiende? Así tengas los mismos estilos en los tres archivos, siempre se aplicarán primero los especificados en la dirección de CSS alternativa, luego los especificados en el control de SharePoint en tu Master Page, y por último los de CORE.CSS.

Utilizar un CSS totalmente distinto

Todo lo anterior (hacer una copia de CORE.CSS) funciona a la perfección cuando partes de un Master Page basado en default.master, pero si quisieras aplicar tus propios estilos a un Master Page basado por ejemplo, en mi xMP, esto no te servirá.

Por que?! Porque a menos que las etiquetas HTML, ASP.NET y controles SharePoint de tu Master Page llamen a las mismas clases que son llamadas desde default.master hacia CORE.CSS (o mejor dicho, CORE-COPY.CSS), tendrás que definir tus propias clases y asociarlas a tu nuevo Master Page.

Ejemplo: MyDefault.master utilizando CORE-COPY.CSS

Aquí notamos que las clases llamadas son definidas en CORE-COPY.CSS y son las mismas definidas en CORE.CSS

Cuando utilices el Minimal Master Page, o el xMP, no tendrás estas referencias a clases, y a menos que las copies de, por ejemplo, default.master, de nada servirá que trabajes personalizando una copia de CORE.CSS

Es por esto, que si quieres que tu sitio luzca, por ejemplo, así

(http://www.westernaustralia.com –MOSS baby, MOSS!)

será mejor que empieces de CERO a partir de xMP y que a cada elemento en la vista de código le asocies clases creadas por ti, y que utilices un CSS creado por ti, ya no a partir de CORE.CSS, sino uno totalmente nuevo, definiendo las clases que TU crees, así

Asocias al Master Page un archivo CSS totalmente nuevo (misEstilos.CSS??), primero a modo de debugging en el disco, luego cuando hayas terminado, a la Biblioteca de Estilos. Tu archivo CSS deberá tener entonces únicamente las clases que tu definas (como .fondoBanner, por ejemplo). Por los estilos que definen las páginas administrativas, ni te preocupes (a menos claro, que quieras cambiarlos también), siempre estará CORE.CSS como “fondo” o “piso” para los estilos que no definas –lo que ocurre realmente es que las páginas administrativas, o páginas “_layouts”, normalmente no son personalizadas (no está recomendado y no sé exactamente si está soportado), de modo que tu Master Page será aplicado al sitio visible para los usuarios, mientras que las páginas administrativas siguen utilizando su Master Page por defecto (application.master), entonces realmente no tiene nada que ver una cosa con la otra.

Conclusiones

- MOSS emplea extensivamente CSS en los Master Pages que utiliza

- Existen al menos tres capas de CSS, teniendo mayor prioridad la hoja CSS alternativa, luego la(s) asociada(s) al Master Page, y por último CORE.CSS.

- No debes modificar de ningún modo CORE.CSS, nunca.

- Luego de hacer debugging y pruebas de tu CSS en disco, pásalo a la Biblioteca de estilos del sitio.

- Para personalizaciones muy avanzadas, es recomendable no basarte en default.master, sino en un Master Page base, tal como xMP, o el de Heather, y crear tus propios estilos.

Con este artículo (y algunos anteriores) concluyo una serie de artículos dedicados al Branding de MOSS. Creo que, sobre todo, este artículo y el anterior, explican de manera clara y amigable (eso espero ) los tips de cómo personalizar una implementación de MOSS. Como mencioné al iniciar la serie, estos tips son los que yo he venido aprendiendo desde Beta 2 y que me han permitido personalizar profundamente sitios MOSS. Adicionalmente, mucha de esta información está publicada de modo formal en MSDN y TechNet.

Referencias

Guía CSS de SharePoint (Core.css): http://www.sharepointblogs.com/jeanmarc/archive/2007/07/20/3201.aspx

CSS Reference Chart for SharePoint 2007: http://www.heathersolomon.com/content/sp07cssreference.htm

Branding SharePoint – Part 1: Designing your SharePoint Site - http://www.heathersolomon.com/blog/articles/brandsppart1.aspx

Branding SharePoint - Part 2: Creating the Design in SharePoint - http://www.heathersolomon.com/blog/articles/brandsppart2.aspx

Master Page debugging 1: Place Holders - http://www.sharepointblogs.com/jeanmarc/archive/2007/09/14/5828.aspx

Espero que sirva!

-.M.-

Hola a todos. Tengo pendiente la segunda parte del artículo relacionado a la personalización de Master Page (Master Page Debugging 1: PlaceHolders). Ahora he avanzado bastante al respecto, pero la demora se debe a que hace mas de una semana he estado no solo con asma (si, desde los 2 años), sino con una inflamación bronquial terrible que se complicó mas de lo esperado.Es por eso que todavía no sale el artículo.

Durante este fin de semana avanzaré bastante, ya que no podré salir a dar vueltas (ando realmente mal!), y Valeria se queda conmigo, so no need to move away from here.

-.M.-

Si quieres actualizar la información que aparece en los resultados de búsquedas de personas, como fotos, intereses, conocimientos, etc, y que sean vivibles inmediatamente, entonces debes:

1. Actualizar la información (via AD y manualmente también --cada usuario puede editar su perfil y debe ser alentado a hacerlo)
2. Importar perfiles desde la Administración del Shared Service
3. Realizar un rastreo incremental al índice.

Así, podrás ver los resultados inmeadiatamente.

-.M.-

Hace tiempo que quería escribir este artículo...

Antes de empezar

Este no es un artículo de desarrollo neto. Si estás buscando artículos de desarrollo relacionados a Master Pages, mejor revisa www.sharepointblogs.com. Este es un artículo enfocado a diseño gráfico. Para profundizar en esto, busca a Heather Solomon (http://www.heathersolomon.com/blog/)

Background teórico

ASP.NET 2.0 introduce el concepto de Master Page. Esto, para quienes alguna vez hayan utilizado, por ejemplo, Dreamweaver para diseñar un sitio web, es equivalente al uso de plantillas.

En pocas palabras, un Master Page es un archivo con extensión .master que sirve como “plantilla” para todo el resto de páginas que creemos en nuestra aplicación web. Hey, no vamos a programar (ni diseñar gráficamente) la barra de navegación, el menú, el logotipo, la barra de búsqueda, y en general el conjunto de elementos comunes a la gran mayoría (sino todas) las páginas de nuestra aplicación, cierto? Tiene sentido. Lo hacemos una única vez en un Master Page y luego vamos variando el contenido mediante Content Pages, que son archivos .aspx -- los únicos que van variando a lo largo de toda nuestra aplicación. El usuario visualiza en su navegador un archivo aspx que es una combinación de un Master Page (Cualquiera.master) sumado a un Content Page (Contenido.aspx), lo que resulta en, por ejemplo, Default.aspx. Este “junte” entre Master Page y Content Page se realiza “on the fly”, en el momento en que el usuario llama a Default.aspx. Simple no?

El Master Page entonces presenta elementos comunes a todas las páginas. Estos elementos comunes van posicionados en unos contenedores especiales llamados Place Holders. Ejemplo: tienes un Place Holder que contiene la barra de navegación superior, tienes otro para el logotipo del sitio, uno mas para el banner inferior con el “Copyright”, y un último para el contenido principal o cuerpo, que será variable. Ahora, típicamente el Master Page define el posicionamiento de estos Place Holders en la página que el usuario ve (colocándolos dentro de tags HTML de tablas, filas, columnas, etc., o de un modo mas sofisticado empleado el super-fancy-and-hot tag DIV + posicionamiento mediante CSS, conocido como CSS-P… web 2.0 baby!), además de definir la apariencia gráfica de estos elementos (les da el “look and feel”). Lo particular de estos Place Holders es que el Master Page típicamente les proporciona contenido, como por ejemplo, llenar el Place Holder destinado a la barra de navegación con un control ASP.NET de navegación que será común a todas las páginas, PERO los Content Pages que utilicen este Master Page opcionalmente también pueden sobreescribir el contenido de ese Place Holder y mostrar su propia barra de navegación, y de hecho, pueden sobreescribir contenido en TODOS los Place Holders que proporcione el Master Page. AH?!

Ok, lo explicaré con un ejemplo (si te quedó claro entonces puedes saltar el resto de esta sección). Supongamos un Master Page llamado Portal.master, que tiene un banner superior, una barra de navegación superior y un espacio para publicidad en la parte izquierda. Este Master Page será utilizado por toda nuestra aplicación ASP.NET publicada en internet en www.portaldemarcel.com. Nuestro gran portal posee dos páginas de contenido: Inicio.aspx y ListaProductos.aspx, siendo una la página de bienvenida y otra la que muestra los productos que Marcel vende en su portal. Cuando algún usuario entra a www.portaldemarcel.com entonces es recibido por la página inicial, llamada Default.aspx. Esta página de bienvenida es la combinación de Portal.master + Inicio.aspx, como lo muestra el gráfico 1:

Si navegamos hacia la sección de productos, en nuestro navegador recibiremos a Productos.aspx, que será la combinación de Portal.master + ListaProductos.aspx, como lo muestra el gráfico 2:

Ahora, el contenido varía entre la página principal y la página de productos (obviamente), y además, Marcel quiere que la publicidad que se muestre en una u otra página también varíe, mas no su posición. Además, el banner y la barra de navegación superior tampoco deben variar ni en posición ni en contenido ni en texto ni en nada, ok?

Para logar esto, el esquema de Portal.master será el siguiente:

En este caso, Portal.master proporciona 4 placeholders, acomodados en la posición deseada empleando HTML estándar (tablas y otras etiquetas obsoletas ):

• Place Holder para el banner (estático)
• Place Holder para la barra de navegación (estática)
• Place Holder para publicidad (dinámica)
• Place Holder para el contenido principal (dinámico)

Ya que 2 de estos 4 Place Holders son estáticos, entonces Portal.master escribirá contenido en ellos. Este sería el código para el Place Holder del banner (estático):

<asp:ContentPlaceHolder id="PlaceHolderBanner" runat="server">
     <asp:Image ImageUrl="..." AlternateText="..." runat="server" />
</asp:ContentPlaceHolder>

Y este sería el código para el Place Holder del contenido principal (dinámico):

<asp:ContentPlaceHolder id="PlaceHolderMain" runat="server">
</asp:ContentPlaceHolder>

...que es equivalente a (simplemente):

<asp:ContentPlaceHolder id="PlaceHolderMain" runat="server" />

Nota: este código ASP estará rodeado de HTML que le de formato y posición (tablas, filas, columnas, etc.)

Te das cuenta que para el Place Holder del banner (que proporcionará contenido estático) se ha utilizado una imagen? En cambio, para el del contenido principal (dinámico) no se ha puesto nada, está vacío (y es inclusive resumible a una línea).

Porqué es esto así? La respuesta es simple: el Master Page proporcionará el contenido estático, mientras que el Content Page proporcionará el contenido dinámico. Cada Content Page (Inicio.aspx y ListaProductos.aspx) proporcionará no sólo su contenido principal, que irá en el Place Holder destinado al contenido principal, sino también la publicidad que cambiará de acuerdo a la página, que irá en el Place Holder destinado a la publicidad. De modo que un Content Page es el encargado de “llenar” los Place Holders vacíos, y podría llenar también los llenos! --como el banner y la navegación. Efectivamente, cada Content Page podría proporcionar su propio banner y su propia barra de navegación, además de su publicidad y el contenido principal, pero esto difiere de los requerimientos, de modo que para este ejemplo sólo debe preocuparse por el contenido publicitario y principal… ni siquiera de su posición, ya que esto lo define también el Master Page… entonces un Content Page tiene *exclusivamente* código que proporciona contenido, y para nuestro ejemplo, en el caso del contenido principal para la página de bienvenida, sería algo como el siguiente:

<asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">
  <table>
    <tr><td>Bienvenido a www.portaldemarcel.com. Esta es la pagina principal</td></tr>
  </table>
</asp:Content>

Nota: este código NO necesita HTML rodeándolo para darle posición, ya que simplemente otorga contenido al Place Holder correspondiente en el Master Page, quien es el que se encarga de darle posición.

Debes notar que es atributo ContentPlaceHolderId="PlaceHolderMain" tiene el mismo valor que el Place Holder al cual quieres otorgarle (o sobreescribir) contenido. Este es el modo como entregamos el contenido de un Content Page a un Master Page: mediante el ID del PlaceHolder.

De este modo, la página Inicio.aspx, sola, muy aparte de Portal.master, sería la siguiente:

Y la misma página, en combinación con Portal.master, sería la siguiente:

De este modo se construyen tanto Default.aspx como Productos.aspx: mediante la unión de un Master Page y un Content Page, el primero proporcionando los contenedores y la posición (y en algunos casos contenido por defecto) y el otro proporcionando simplemente el contenido que llenará aquellos contenedores.

Como último punto, en caso de que un Content Page NO llene algún Place Holder que NO tenga contenido por defecto, entonces no hay problema, simplemente queda vacío. Pero si un Content Page trata de llenar un Place Holder que el Master Page no proporciona, entonces la página no cargará y obtendremos un error. Es decir: Portal.master podría tener 20 Place Holders posicionados e Inicio.aspx podría seguir otorgando contenido únicamente para 4, o para 2 como en el ejemplo, pero no podría darse el caso de que Portal.Master tenga 4 Place Holders y que Inicio.aspx quiera proporcionar contenido a 20, ni tampoco a otros 4 o 2 o siquiera *alguno* con ID distintos. En ambos casos obtendrías error.

Master Page para MOSS

MOSS se construye sobre ASP.NET 2.0, y utiliza esto mismo: Master Pages y Content Pages a lo largo de prácticamente todos los sitios. Pero a diferencia de nuestra aplicación anterior, para que un Master Page pueda funcionar en MOSS debe llevar una serie de Place Holders especiales, requeridos por MOSS.

El Place Holder que ocupa mayor espacio en las páginas mostradas, y que es por decirlo de algún modo, el mas importante dentro de todos estos muchachos especiales, es el llamado PlaceHolderMain, que actuará del mismo modo como lo hizo en el ejemplo anterior: otorgando el contenido principal de una página.

Dado que el Master Page típicamente define el look de MOSS, seguramente querrás crear tu propio Master Page y darle a ese portal clásico un face-lift, o adecuarlo a los estándares de imagen corporativa de tu organización.

Para ello, Microsoft ha publicado para libre disposición de todo el mundo un Master Page que dispone del mínimo de Place Holders necesarios para que a partir de ahí puedas construir un Master Page revolucionario y que funcione con MOSS: se llama Minimal Master Page (http://msdn2.microsoft.com/en-us/library/aa660698.aspx).

Si examinas este archivo, podrás ver los Place Holders que son absolutamente requeridos para que un Master Page funcione con MOSS.

De modo que el Minimal Master Page DEBE ser SIEMPRE tu punto de partida para la creación de un Master Page desde cero. Claro, puedes tomar libremente pedazos de los Master Pages que MOSS trae por defecto y que están almacenados en el Master Page Gallery de tu colección de sitios raíz, cortando y pegando trozos de estos y poniéndolos en reemplazo de los Place Holders que te trae el Minimal Master Page (reemplazando siempre un Place Holder con determinado ID por otro con el mismo ID, nunca duplicar, nunca eliminar, sólo extender).

Y entonces surge la pregunta: para qué agregar entonces mas Place Holders de los requeridos por MOSS si total, funciona? La respuesta (que la aprendí en la cancha) es que efectivamente, acomodando el Minimal Master Page podrás meterle a MOSS páginas que funcionen, pero no todos los tipos de sitios de MOSS emplean *únicamente* los Place Holders que trae el Minimal Master Page, a decir: Wiki’s, Search Center, entre otros, utilizan Place Holders adicionales a los que trae el MMP (sí, ya me cansé de escribir el nombrecito).

Para ello, he elaborado no un MMP, sino una extensión del MP, que trae TODOS los Place Holders que alguna vez utilizará cualquier página de MOSS. Te salvaste eh…!  Podemos llamarle Complete Core Master Page, o Marcel’s Base Master Page…  creo que me está afectando el sueño =S. En todo caso, está adjunta a este post y puedes descargarla.

Utilizando el “??? Master Page” (algo de Marcel)

Fácil. Carga el xMP (hey, eso me gusta) al Master Page Gallery. Crea un sitio cualquiera, ya sea de blog, wiki, sitio de equipo o de búsqueda (en realidad te recomiendo que crees estos 4 tipos de sitios en particular) y a todos aplícales el xMP (queda). Carga uno de los sitios y verás en cual Place Holder MOSS coloca contenido. Entra a otro de los sitios que creaste y verifica esto nuevamente. Así sucesivamente y verifica si es que, a diferencia de la implementación estándar del sitio (con default.master aplicado), te falta contenido. Si todo sale bien, podrás mover los Place Holders que no son necesarios al panel ASP que está invisible en la parte inferior y eliminar el texto que indica el nombre del resto. En caso de que te falte contenido que sí tenías cuando usabas default.master, es probable que haya ocurrido una de dos cosas (ok, pueden haber ocurrido las dos): que yo me haya olvidado de algún Place Holder oculto y misterioso proporcionado MOSS y que por error lo haya omitido del xMP (muy poco probable ), o que hayas omitido un Control utilizado por MOSS. Control de MOSS?! AH?!

No todo es Place Holders

Aparte de los Place Holders requeridos y los demás, MOSS utiliza controles en un Master Page: tanto controles de usuario (ascx) como controles de publicación y de navegación, y controles propios de SharePoint. Por ejemplo, el control de “Bienvenido Marcel Jeanneau”, es un control de usuario que va en el Master Page (y se llama Welcome.ascx).

Cuando editas alguna página de un sitio que tenga publishing habilitado, te aparecerá un control de edición de página, llamado “Publishing Console”.

Estos controles se registran en el Master Page, y luego se invocan ahí también (se “instancian”, si quieres seguir con lo de ASP.NET). Ciertamente estos controles no son necesarios para que un Master Page, ya sea uno basado en el MMP o en xMP, pueda correr en MOSS, pero serán MUY útiles para cuando publiques un Master Page: imagínate que quieras editar una página y nunca puedas mandarla a aprobación/publicación, o que no dispongas de control de bienvenida (NO SALDRÁ TU NOMBRE!!! Whooooa  --no, en serio, tampoco podrás hacer log-in/log-out), ni tampoco dispondrías del control para entrar a la configuración del sitio (Site actions), ni de navegación… en fin… te das cuenta?

Para entrar solo un poquito en detalle con los controles, son básicamente de 3 tipos:

• Controles de SharePoint: Se encuentran en todas las páginas y son provistos por Microsoft.SharePoint.Portal.dll (WSS v.3) y/o por Microsoft.SharePoint.dll (MOSS 2007). Se identifican por los prefijos “SPSWC”, “SharePoint” o “WebPartPages”. Ej: control de búsqueda insertado en los Master Pages (SPSWC:RightBodySectionSearchBox)

Las páginas publicadas pueden contener Web Parts. El control SPWebPartManager debe estar presente para poder manejarlos .

• Controles de Publicación (WCM): Se encuentran en los sitios que proveen WCM, y son provistos por Microsoft.SharePoint.Publishing.dll. Se identifican por los prefijos “PublishingWebControls” (visibles) y “PublishingNavigation” (no visibles directamente en la página) Ej: el control que contiene el menú “Site Actions” y el control de usuario “Welcome” (PublishingWebControls:AuthoringContainer)

NOTA: Los controles que utilizan el prefijo PublishingNavigation no son controles visuales (ej: PublishingNavigation:PortalSiteMapDataSource) y añaden una capa encima del modelo de Site Map Provider provisto por ASP.NET 2.0. Sirven para entregar al Master Page los datos necesarios que requieren los controles de navegación (ej: SharePoint:AspMenu) para construir adecuadamente los menús del sitio.

Acerca de la navegación: Los controles visuales de navegación (menús), tal como SharePoint:AspMenu, están definidos en el Master Page y llaman a algún Data Source, tal como SiteMapDataSource1, identificándolo por el atributo datasourceID (datasourceID=“SiteMapDataSource1"). Luego, la definición del Data Source va dentro de algún control PublishingNavigation:PortalSiteMapDataSource, identificada por el atributo ID (ID=“SiteMapDataSource1"), y éste a su vez llama a un proveedor (provider) que es quien le entrega los datos, a través del atributo SiteMapProvider (SiteMapProvider=“GlobalNavSiteMapProvider"). La definición del proveedor va en el archivo web.config de la aplicación web, y éste invoca a Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider.dll y a Microsoft.SharePoint.Publishing para conectarse a la base de datos de contenido, que es la que finalmente contiene la información acerca de la jerarquía de sitios.

Y visto en código:

• Controles de usuario ASP.NET: Se pueden encontrar controles de usuario ASP.NET (.ascx) insertados en el Master Page, adicionalmente a los controles ASP.NET de servidor
  Normalmente son:
  
• Welcome.ascx: se muestra en la parte superior de las páginas
  
  
• VariationsLabelMenu.ascx: es usado cuando una página pertenece a una jerarquía de variaciones
  
• PublishingActionMenu.ascx: es el menú Site Actions, el cual cambia de nombre en sitios que no usan WCM
  
  
• PublishingConsole.ascx: presenta los controles del ciclo de publicación de una página
  

Afortunadamente, MMP trae *algunos* de estos controles. Mejor aun, xMP trae TODOS los controles que necesitarás para poner esto en marcha . Tendrás barra de navegación superior y lateral, todos los Place Holders requeridos y los adicionales, controles de usuario, de publicación y de navegación (las barras de navegación son este tipo de controles)… en fin, no te faltará nada de lo que necesitas para iniciar la creación de tu propio Master Page…

No todo es todo lo anterior

Ok, colocaste los Place Holders y controles, probaste y el contenido carga perfectamente, puedes editar, publicar… en fin, un éxito, pero hey, espera: por qué todo luce como un esqueleto? No hay color, vida, estilo ni elegancia! Esto no parece MOSS, parece mi Hello World en HTML 1.0!!

Cierto, te falta una, UNA cosa: asociar una hoja de estilos CSS al Master Page. Nada mas? Sí, nada mas. Pero esa hoja de estilos debe tener TUS estilos, y estos estilos deben estar asociados a CADA componente (placeholder, control, tag, etc) del Master Page al cual le quieras dar formato… o sea que tu “nada mas?” se convierte en “mucho mas!!”. Pero dejo eso para el siguiente post, mañana tengo examen de finanzas…

-.M.-

Hola a todos, les cuento que ya tengo mi blog relacionado a Comunicaciones Unificadas, se llama Unified Clarifications! (http://msclarifications.blogspot.com/).

Estaré publicando lo que pueda compartir con respecto a Exchange 2007 y Office Communications Server 2007, tal como lo he venido haciendo aquí con SharePoint.

Si a alguien le interesa ese tema, pues puede sindicar mi nuevo blog mediante este link --> http://msclarifications.blogspot.com/feeds/posts/default?alt=rss

Estoy bastante emocionado respecto a esta nueva área de trabajo, y pronto estaré compartiendo mis experiencias, apuntes y cosas que muchas veces no resultan obvias.

-.M.-

Por fin! Microsoft lanzó su propia herramienta de creación de definiciones de aplicaciones para BDC, llamada "Business Data Catalog Definition Editor", la cual está disponible con la ueva versión (1.2) del SDK de MOSS (agosto 2007). Por cierto, Ishai Sagi de SharePoint Tips And Tricks ya la ha probado y según su post, requiere la instalación de SQLEXPRESS para el funcionamiento de la herramienta, de modo que será necesario utilizarla en un servidor de pruebas sin MOSS ni WSS.

Además de esta herramientas, otros nuevos ejemplos han sido incluidos en esta última versión del SDK,

BDC

• WSHelloWorld Web Service
• Excel Services User Defined Function Sample
• WSOrders Custom Proxy Sample
• SAP Sample (vamos a ver de qué se trata!)

Search

• Sample Protocol Handler
• Custom Content Source

Records Management

• IRM Document Protector

Espero probar esto durante el fin de semana y compartir algunos resultados... mientras tanto, continúo mi training en Exchange 2007

-.M.-

Según el siguiente KB: http://support.microsoft.com/default.aspx/kb/938499/ (An external storage API is available for Windows SharePoint Services 3.0), el hotfix 937901 (http://support.microsoft.com/kb/937901/) proporciona un API para el almacenamiento de documentos y archivos para un site, fuera de SQL Server. This rocks!

He tratado de seguir los links para ver de qué se trata, aunque ha sido infructuoso.. veamos entonces la última versión del SDK de WSS o de MOSS (Agosto 2007)...

-.M.-

Hace unos días instalé un firewall personal llamdo GhostWall en mi laptop (cpu Turion 64-bit). No hay muchos firewalls personales que corran en arquitectura 64-bit!! Es un firewall de filtrado de paquetes, lo que es un tanto difícil de manejar para quienes no están familiarizados con temas de networking tales como IPs, puertos, servicios, protocolos, etc., pero me gusta bastante porque me recuerda a los viejos tiempos de netfilter + IPtables, y a mi parecer es bastante bueno. Además, en combinación con Windows Firewall (utilizo W2K3 R2 SE SP1) hacen un gran duo --recordar que a diferencia de los anti-virus, que generalmente no conviven bien mientras ya haya algún otro instalado, los firewalls típicamente sí pueden coexistir, sobretodo cuando se presentan situaciones como esta: firewall de filtrado de paquetes (capa 3, 4) + firewall a nivel de aplicación (capa 7).

Como administradores SharePoint, quizás alguna vez hayan buscado información acerca de qué puertos se necesitan administrar --hace 4 años los administradores de red de mi facultad me preguntaron eso y tuvimos que rastrear manualmente el tráfico para poder determinar la info... parece que todo era complicado en los dias de SPS2003!!! ja

Joel Oleson publicó esta lista hace bastante tiempo, y está aquí: Protocols, Ports, and Firewall Rules (http://blogs.msdn.com/joelo/archive/2007/02/13/protocols-ports-and-firewall-rules.aspx)

Por otro lado, la lista de puertos, servicios y protocolos para Windows Server 2003, en todas sus ediciones, está aquí: Service overview and network port requirements for the Windows Server system (http://support.microsoft.com/kb/832017)

Espero que esta info sea últil.

-.M.-

Hoy he sido asignado a ver Unified Communications, lo que agregará Exchange y Communications Server a mi lista de trabajo!

Esto implica que dejaré de escribir tan seguido en este blog, o mejor aún, que los posts que escriba estarán relacionados a SharePoint + Exchange + Communications Server. Hasta ahora no he visto blogs relacionados a esto! (me refiero a los tres productos).

Espero que quienes me tengan sindicado en su lector RSS no me borren ya que no es un adios sino un hasta luego! Tengo que iniciar mi entrenamiento en Exchange y Communications server, lo que demandará el 100% de mi tiempo... prometo regresar corregido y aumentado!!

Saludos a todos

-.M.-

Introducción

Vamos a elaborar una plantilla o definición de sitio de acuerdo a las necesidades de la organización, a partir de una definición ya existente. Muchas veces las definiciones otorgadas por MOSS (o WSS) carecen de algún componente en particular, ya sea algún web part, imagen o cualquier elemento que pueda colocarse en un sitio web SharePoint, de acuerdo a los requerimientos organizacionales, para la creación de uno o varios sitios web. Es dentro de este contexto que desearemos crear una definición de sitio personalizada. Típicamente no crearemos una plantilla de sitio desde cero sino que tomaremos como base alguna definición ya existente (la que más se acerque a nuestro resultado deseado) y la modificaremos de acuerdo a las necesidades.

Una definición de sitio especifica o "define" (perdón por la redundancia) uno o varios tipos de sitios (también llamados plantillas), como pueden ser Sitio de Grupo, Sitio en Blanco, etc, todos parte de una sola definición, pero empleando una configuración individual por cada sitio.

Escenario

La plantilla que crearemos será una variación de la plantilla de “Sitio de grupo”, la cual mostrará en lugar del logo de Windows SharePoint Services, un logo personalizado cada vez que se cree un sitio utilizando ésta plantilla.

Preparación

Antes de empezar, debemos copiar el archivo logoCustom.gif (adjunto a este post) hacia la carpeta C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\IMAGES de nuestra VPC:

1. Descargamos el archivo logoCustom.gif
2. Luego vamos a la VPC y hacemos WINDOWS + E
3. Damos doble clic en Local Disc (C:)
4. Damos doble clic en Program Files
5. Damos doble clic en Common Files
6. Damos doble clic en Microsoft Shared
7. Damos doble clic en web server extensions
8. Damos doble clic en 12
9. Damos doble clic en TEMPLATE
10. Damos doble clic en IMAGES
11. Ahora arrastramos el archivo logoCustom.gif hacia la carpeta C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\IMAGES de nuestra VPC
12. No cerramos el explorador de Windows de la VPC ya que lo continuaremos utilizando

Accediendo al sistema de archivos

Para crear una definición de sitio tenemos que tener acceso al sistema de archivos de cada uno de los servidores web de front-end. En este caso tenemos un solo servidor entonces lo haremos una sola vez, pero el trabajo realizado de aquí en adelante se debe repetir idénticamente en cada servidor web de front-end que tengamos en la implementación.

1. Subimos un nivel en el sistema de archivos 
2. Esto nos deja en la ruta C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE. Ahí observamos el siguiente esquema de carpetas:

Debemos prestar especial atención a las carpetas “3082” y “SiteTemplates” ya que éstas contienen archivos que necesitaremos modificar para la creación de nuestra plantilla. 

3. Damos doble clic a la carpeta “SiteTemplates”. Podremos observar muchas carpetas. Cada una de éstas carpetas contiene una definición de sitio con múltiples plantillas cada una, proporcionadas por SharePoint. Lo que haremos es tomar una definición como base y realizarle modificaciones.
4. Damos clic derecho a la carpeta “sts” y elegimos Copy.
5. Subimos un nivel en el sistema de archivos. 
6. Hacemos clic derecho y elegimos la opción Paste.
7. Una vez pegada la carpeta la seleccionamos haciéndole clic.
8. Damos un clic en el nombre para poder cambiarlo. El nombre se resaltará en azul.
9. Le damos el nombre “CUSTOM” y apretamos Enter.
10. Damos clic derecho a ésta carpeta y seleccionamos la opción Cut.
11. Damos doble clic a la carpeta “SiteTemplates”.
12. Damos clic derecho en el contenido y elegimos la opción Paste.
13. Subimos un nivel en el sistema de archivos. 
14. Hacemos doble clic en la carpeta 3082.
15. Hacemos doble clic en la carpeta XML. Ubiquemos el archivo WEBTEMP.XML
16. Damos clic derecho a WEBTEMP.XML y elegimos la opción Copy.
17. Subimos un nivel en el sistema de archivos. 
18. Hacemos clic derecho y elegimos la opción Paste.
19. Una vez pegado el archivo lo seleccionamos haciéndole clic.
20. Damos un clic en el nombre para poder cambiarlo. El nombre se resaltará en azul.
21. Le damos el nombre “WEBTEMPCUSTOM.XML” (sin comillas) y apretamos Enter.
22. Damos clic derecho a éste archivo y seleccionamos la opción Cut.
23. Hacemos doble clic en la carpeta XML.
24. Damos clic derecho en el contenido y elegimos la opción Paste. –es absolutamente necesario que el sufijo del nombre de éste archivo coincida con el nombre de carpeta de nuestra nueva definición, en este caso CUSTOM.

Creando nuestra definición de sitio

1. Damos clic derecho al archivo WEBTEMPCUSTOM.XML y seleccionamos la opción Modificar con Office SharePoint Designer. Se abrirá SharePoint Designer con el archivo. Aquí definiremos cuántos tipos de sitios nos otorgará la definición CUSTOM, agrupados por plantillas mediante las etiquetas <Template />, especificando el sitio dentro de cada plantilla mediante la etiqueta <Configuration />.
2. Borramos el código de modo que nos quedemos únicamente con lo siguiente:

Sólo nos quedamos con la plantilla de nombre “STS”, que es la que finalmente utilizaremos como base para nuestra nueva definición.

3. Borramos toda la línea que tiene <Configuration ID=1… >
4. Borramos toda la línea que tiene <Configuration ID=2… >
5. Reemplazamos el atributo Name de “STS” a “CUSTOM”
6. Reemplazamos el atributo ID de <Template> de 1 a 10001 (el ID siempre debe ser único y mayor que 10000).
7. Reemplazamos el título de “Sitio de grupo” a “Sitio de equipo CUSTOM”
8. Reemplazamos la descripción por “Este es un sitio creado para este How-To. Provee una Biblioteca de Documentos y listas para administrar anuncios, un calendario, tareas y discusiones”.
9. Verificamos que el resultado final sea el mostrado en la siguiente figura:

10. Salvamos los cambios. En este archivo se define únicamente el título, la disponibilidad, la imagen previa y la descripción mostrada en la pantalla a la hora de seleccionar una plantilla para un nuevo sitio.
11. Regresamos al Explorador de Windows que tenemos abierto y presionamos dos veces el botón   para poder ubicarnos en el directorio C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE
12. Hacemos doble clic en la carpeta SiteTemplates
13. Hacemos doble clic en la carpeta CUSTOM
14. Hacemos doble clic en la carpeta xml
25. Damos clic derecho en el archivo ONET.XML y elegimos la opción Modificar con Office SharePoint Designer. En este archivo podemos (http://msdn2.microsoft.com/en-us/library/ms474369(d=printer).aspx):

a. Definir los links del menú izquierdo para el Home Page de los sitios, pero se aplicarán a la vez para todas las plantillas de la definición, dentro del elemento <NavBars /> (http://msdn2.microsoft.com/en-us/library/ms430616.aspx)
b. Las listas disponibles para poder crearse a partir de la página “Crear”, dentro del elemento <ListTemplates /> (http://msdn2.microsoft.com/en-us/library/ms439434.aspx).
c. Las listas y Web Parts que vendrán ya instaladas en una determinada configuración, dentro de cada elemento <Module /> (http://msdn2.microsoft.com/en-us/library/ms460356.aspx)referenciado por cada elemento <Configuration /> (http://msdn2.microsoft.com/en-us/library/ms476942(d=printer).aspx) --que se enlaza a WEBTEMPCUSTOM.XML mediante el atributo ID.
d. Definir si éstos elementos se muestran o no en la barra de navegación izquierda.
e. Las plantillas para cada tipo de documento que se utilice en el sitio (Word, Excel, etc.) mediante el elemento <DocumentTemplateFiles /> (http://msdn2.microsoft.com/en-us/library/ms416769.aspx), así como las plantillas para bibliotecas de documentos (http://msdn2.microsoft.com/en-us/library/ms411227.aspx).
f. Los Features que dispondrá la colección de sitios mediante el elemento <SiteFeatures /> (http://msdn2.microsoft.com/en-us/library/ms469685.aspx), así como los Features disponibles a nivel de subsitio, mediante el elemento <WebFeatures /> (http://msdn2.microsoft.com/en-us/library/ms467789.aspx)
g. etc etc etc (ver SDK: Onet.xml --> http://msdn2.microsoft.com/en-us/library/ms474369(d=printer).aspx)

Nota:
Cada etiqueta <Configuration /> en WEBTEMPCUSTOM.XML debe tener un atributo ID con un valor que coincide con el valor del atributo ID de la etiqueta <Configuration /> en el archivo ONET.XML

15. Ahora cambiaremos la imagen por defecto que muestra cada sitio creado mediante nuestra plantilla. Para ello, vamos a la línea 173 del código.
16. Reemplazamos el nombre de archivo /_layouts/images/homepage.gif (dentro de <iwp:ImageLink>) por /_layouts/images/logoCustom.gif. Cabe mencionar que estamos dentro del módulo con nombre “Default” (<Module Name="Default" Url="" Path="">), que es utilizado por la configuración con ID=0 (<Configuration ID="0" Name="Default">), la cual es la única que utilizamos en WEBTEMPCUSTOM.XML.
17. Salvamos los cambios y salimos de SharePoint Designer.
18. Para que los cambios se vean reflejados debemos reiniciar la aplicación web. Damos clic en Start, Run y escribimos iisreset, seguido de Enter.

Creación de un sitio con nuestra definición

1. Abrimos una ventana de Internet Explorer
2. En la barra de direcciones escribimos http://<servidor> seguido de Enter
3. Ahora podemos crear un sitio utilizando nuestra plantilla. Para ello hacemos clic en Acciones del Sitio, Crear Sitio y podremos ver nuestra plantilla disponible para su uso

4. Escribimos en Título “Sitio del Curso”
5. Escribimos en Descripción “Este es un sitio que hemos creado con nuestra propia plantilla”
6. En Dirección del sitio web escribimos “customSite”
7. En la Selección de Plantilla hacemos clic en “Sitio de equipo CUSTOM” tal como lo muestra la figura anterior
8. Damos clic en Crear
9. Hemos creado el sitio con nuestra propia plantilla y con una imagen personalizada, tal como lo muestra la figura

Notas finales

• El estudio de ONET.XML es exhaustivo. Realmente no proporciona únicamente la funcionalidad especificada en este tutorial, sino mucha más.
• Tal como lo menciona Joel Oleson, hacer iisreset cuando se desea reciclar un único pool de aplicaciones es primitivo, existen "alternativas civilizadas" (http://blogs.msdn.com/joelo/archive/2007/07/16/iisreset-is-bruteforce-there-are-civilized-alternatives-iisapp-vbs.aspx)
• Estoy trabajando actualmente en una definición de sitio para un cliente, y espero compartir las lecciones aprendidas, al tratar de crear sitios con un Master Page propio (incluyendo CSS, imágenes, etc.), Page Layouts propios y categorías de selección propias también.
• Prestar bastante atención al elemento <Module /> (http://msdn2.microsoft.com/en-us/library/ms460356.aspx), ya que aquí se especifican los webparts y archivos a incluir en la definición.

-.M.-

Se ha actualizado el contenido relacionado a mirroring con WSS, el link es http://technet2.microsoft.com/windowsserver/WSS/en/library/3f4c5175-9259-4dba-924a-4d2d76bbe9bc1033.mspx?mfr=true

Respecto a MOSS, yo he tratado de configurar mirroring de acuerdo al whitepaper publicado (http://technet2.microsoft.com/Office/en-us/library/80609398-b01d-4d0a-b429-040b74cae51c1033.mspx?mfr=true), es mas, la configuración por parte de SQL Server funcionó correctamente (http://www.sharepointblogs.com/jeanmarc/archive/2007/06/25/2317.aspx) pero no pude lograr que MOSS reconociera al nuevo servidor.

Existen algunos tips para esto, se me ocurre disparar un script actualizando etc/hosts en todos los servidores para "enmascarar" al servidor principal y poner como titular al espejo, o utilizar aliases de DNS o aliases de SQL Server... pero quiero que funcione con comandos de MOSS!! Alguien lo ha logrado? Inclusive le escribí a Joel Oleson pero ha seguido viendo el tema y no tengo respuesta todavia --a propósito, ha escrito un post respecto a mirroring y log shipping --> http://blogs.msdn.com/joelo/archive/2007/07/30/mirroring-log-shipping-and-high-availability-resources.aspx

-.M.-

A continuación muestro algunas referencias de CSS comunmente utilizadas para personalizar un sitio SharePoint. Esto junto con la guía de Heather Solomon (http://www.heathersolomon.com/content/sp07cssreference.htm) será mas que sificiente para la creación de temas propios y/o la personalización de una hoja de estilos para un master page.

Haz clic en cada imagen para verla en tamaño real

Notas

• Estas clases aplican a un master page que utilice como base CORE.CSS (tal como default.master)
• NUNCA trabajes directamente sobre CORE.CSS
• Crea una copia de CORE.CSS (en el file system), asóciala a tu master page y empieza a editar esta copia. Una vez que tengas los resultados deseados sube este CSS a la galería de estilos del sitio y actualiza la referencia en el master page.
• Estas referencias también te servirán para crear temas de sitio.

-.M.-

Introducción

Los Temas de Sitio son esquemas visuales que nos permiten cambiar instantáneamente los colores, íconos, botones, formato de letras y bordes de web parts para un sitio en particular una vez que éste ya ha sido creado. La personalización mediante temas es conveniente si es que se quiere cambiar un solo sitio en particular, y no afecta a los sub sitios de éste. Si se quiere cambiar todos los sitios de una colección de sitios entonces la utilización de temas no es conveniente ya que se tendría que aplicar manualmente el tema a cada uno de los sitios. Típicamente no crearemos un tema de sitio desde cero sino que tomaremos como base alguno ya existente (el que más se acerque a nuestro resultado deseado) y lo modificaremos de acuerdo a las necesidades.

Escenario

El tema que crearemos será una copia del tema Fronda que incluye SharePoint. Una vez creado este tema podremos, posteriormente, reemplazar íconos y estilos para cambiar la apariencia visual del sitio.

Preparación

Antes de iniciar este laboratorio, debemos copiar el archivo thMiTema.gif (adjunto a este post) hacia la carpeta C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\IMAGES

Adicionalmente tendremos que cargar un Web Part (Visor_de_codigo_CSS.dwp, también adjunto) que nos permitirá visualizar estilos (descárgalo al escritorio de tu servidor SharePoint).
Accediendo al sistema de archivos

Para crear un tema de sitio, tenemos que tener acceso al sistema de archivos de cada uno de los servidores web de front-end. En este caso tenemos un solo servidor entonces lo haremos una sola vez, pero el trabajo realizado de aquí en adelante se debe repetir idénticamente en cada ser