Dentro de SharePointCreación de una infraestructura para SharePoint
Pav Cherny
Descargar el código de este artículo: SharePoint2008_05.exe (412KB)
Al igual que la mensajería de correo electrónico transformó las comunicaciones en los negocios, la colaboración basada en web está cambiando la manera en que los empleados trabajan y comparten información. Si desea un buen ejemplo, no dude en observar lo que le ofrece la tecnología SharePoint. Gracias a Microsoft Windows SharePoint Services (WSS) 3.0 y Microsoft Office SharePoint Server
(MOSS) 2007, es posible crear sitios de grupo, portales, soluciones de administración de contenido web, bibliotecas de documentos y centros de búsqueda, por no mencionar la integración de 2007 Microsoft® Office system, formularios basados en XML, flujos de trabajo, compatibilidad con movilidad, etc.
No obstante, le recordamos que no es siempre sencillo empezar a usar SharePoint®. La terminología puede ser confusa. La arquitectura de sistema puede ser compleja y SharePoint requiere la administración de múltiples componentes, incluidos IIS, Microsoft .NET Framework, SQL Server® y, posiblemente, otras tecnologías como Business Intelligence, InfoPath® Forms Services, Rights Management Services (RMS), Exchange Server y ForefrontTM Security.
Es muy frecuente perderse dentro de integraciones y personalizaciones dados los numerosos enfoques que puede adoptar para crear soluciones de SharePoint, bien a través de la interfaz de usuario integrada o bien mediante programación. Además, cuando una aplicación SharePoint no funciona, la solución de problemas puede ser complicada. Con frecuencia, deberá tener la mentalidad de un desarrollador de aplicaciones para comprender los componentes implicados y cómo interactúan. Con todos estos desafíos, ¿por dónde empezar para crear una infraestructura de SharePoint eficaz, escalable y fácil de administrar?
En esta columna, le mostraré cómo empezar, en primer lugar, creando una base con un análisis de alto nivel sobre arquitectura y adentrándome, a continuación, en la implementación de WSS, incluidas personalizaciones de marca muy básicas. Mediante la característica Administración de sitios sin intervención del administrador de WSS 3.0, podrá ver cómo delegar permisos a usuarios individuales para crear y administrar sitios de SharePoint al tiempo que se mantiene el control administrativo centralizado sobre la infraestructura de SharePoint.
Si observamos, en primer lugar, la arquitectura de SharePoint, es más sencillo comprender la implementación y configuración de los pasos necesarios para implementar una infraestructura flexible y escalable. Así pues, observemos las dependencias y, a continuación, abordemos directamente la implementación de WSS 3.0. Para obtener las instrucciones detalladas de implementación, consulte el material complementario para su referencia. Puede encontrar este material en la sección de descargas del sitio web de TechNet Magazine en technetmagazine.com.
Arquitectura de SharePoint
Con SharePoint, es útil abordar la tecnología desde el punto de vista de un arquitecto de sistema. No tiene por qué conocer todos los detalles, pero si está familiarizado con las dependencias generales que surgen desde la arquitectura de SharePoint, puede obtener soluciones de una forma más rápida pues es posible anticipar lo que necesita configurar y por qué.
SharePoint es una tecnología dirigida al aprovisionamiento de aplicaciones y sitios web. Es una solución de sitio web basada en IIS, que se integra con IIS a través de ASP.NET y que depende de una base de datos de SQL Server para almacenar datos de configuración y contenido. En resumen, SharePoint combina tres arquitecturas diferentes en su núcleo (IIS, .NET y SQL Server), tal como se ilustra en la Figura 1.
Figura 1** Arquitectura de WSS 3.0 basada en IIS 6.0 y ASP.NET 3.0 **(Hacer clic en la imagen para ampliarla)
No se deje intimidar por el diagrama. La arquitectura puede parecer muy complicada en un principio, teniendo en cuenta el número total de componentes. Pero todos estos componentes se ajustan a un marco lógico que, cuando se examina sistemáticamente, nos ofrece una introducción a las dependencias de los componentes.
Tal como se ha descrito, SharePoint depende de IIS y ASP.NET para administrar las solicitudes y respuestas HTTP. Los componentes estándar de IIS, como el controlador modo kernel HTTP (http.sys) y el proceso de trabajo (w3wp.exe), llevan a cabo la puesta en cola y el enrutamiento iniciales de las solicitudes hasta que éstas llegan al filtro ISAPI de ASP.NET (aspnet_isapi.dll). Al instalar .NET Framework, la rutina de instalación registra aspnet_isapi.dll en la metabase de IIS (C:\Windows\System32\Inetsrv\metabase.xml), del siguiente modo:
InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
Una vez que IIS carga el filtro ISAPI de ASP.NET, todas las solicitudes entrantes para un sitio web pueden pasarse a ASP.NET, lo cual es importante ya que SharePoint debe recibir, eventualmente, estas solicitudes a través de ASP.NET. Para poder conseguirlo, SharePoint extiende la configuración del sitio web seleccionado al filtro ISAPI de ASP.NET, agregando un mapa de aplicación de comodines que enruta todas las solicitudes entrantes, independientemente de la extensión de nombre de archivo.
Puede comprobar lo explicado en Administrador de IIS, una vez haya instalado WSS 3.0 mediante la opción de instalación básica. La rutina de instalación de WSS desactiva el sitio web de IIS predeterminado en el servidor y crea un nuevo sitio web predeterminado en el puerto 80 que tiene definido el mapa de aplicación de comodines de ASP.NET, tal como se muestra en la Figura 2.
Figura 2** Mapa de aplicación de comodines del filtro ISAPI de ASP.NET **(Hacer clic en la imagen para ampliarla)
Para que ASP.NET pase a cambio solicitudes a SharePoint, éste último debe, asimismo, extender la canalización de solicitud HTTP a través de un objeto personalizado HttpApplication, que se implementa gracias a una clase denominada SPHttpApplication en el ensamblado Microsoft.SharePoint. SharePoint define este objeto de aplicación personalizada en el archivo de aplicación de ASP.NET (global.asax), el cual puede encontrar en el sistema de archivos de la carpeta raíz de sitios web extendidos de SharePoint. El siguiente código muestra el contenido del citado archivo global.asax:
<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>
ASP.NET analiza y compila de forma dinámica este archivo para crear instancias del objeto de aplicación de SharePoint.
Para cada solicitud recibida, ASP.NET activa una serie de eventos que la aplicación web puede procesar como, por ejemplo, BeginRequest, AuthenticateRequest, ProcessRequest y EndRequest. Los detalles del control de eventos van más allá del alcance de la implementación y administración de SharePoint, si bien es importante saber que, además del SPHttpApplication especificado en global.asax, SharePoint implementa controladores y módulos HTTP personalizados definidos en el archivo web.config del sitio. Por ejemplo, SharePoint usa un módulo HTTP basado en la clase SPRequestModule, registrado como el primer módulo HTTP anterior a los módulos ASP.NET estándar. SPRequestModule puede inicializar el entorno de tiempo de ejecución de SharePoint registrando, por ejemplo, un componente SPVirtualPathProvider con ASP.NET. SPRequestModule es para un uso interno de SharePoint, pero los desarrolladores de soluciones de SharePoint pueden modificar el archivo web.config para que registre componentes adicionales, como controladores y módulos HTTP personalizados. A través de módulos HTTP tanto personalizados como estándar, SharePoint saca provecho de ASP.NET al mismo tiempo que mantiene un control exhaustivo sobre todas las solicitudes a las aplicaciones SharePoint.
Tenga en cuenta que cuando crea una aplicación web mediante el sitio de Administración central de SharePoint 3.0, WSS agrega el mapa de aplicación de comodines de ASP.NET al sitio web de IIS seleccionado y crea los archivos global.asax y web.config en la carpeta raíz del sitio web. Cada aplicación web usa su propio conjunto de archivos de nivel superior global.asax y web.config.
Para procesar las solicitudes y devolver una información significativa a los exploradores, WSS 3.0 y MOSS 2007 dependen del analizador de páginas estándar de ASP.NET, que compila las páginas solicitadas de ASP.NET o las procesa sin modo de compilación. Pero las páginas de ASP.NET que SharePoint pasa al analizador de ASP.NET no se ubican necesariamente allí donde parecen existir. Por ejemplo, no le será posible encontrar un archivo default.aspx file en la carpeta raíz de un sitio web extendido de SharePoint, como el sitio de Administración central de SharePoint 3.0, sin embargo, podrá abrir default.aspx cuando se muestre la página principal de ese sitio web. Es el componente SPVirtualPathProvider el que virtualiza el entorno al cargar el contenido de la página desde el sistema de archivos local o una base de datos de contenido de SQL Server y lo pasa como un archivo virtual al analizador de páginas de ASP.NET. Para el sitio de Administración central, SharePoint carga el archivo default.aspx desde la carpeta C:\Archivos de programa\Archivos comunes\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin.
La página principal, así como la mayoría de las páginas del sitio de SharePoint, están vinculadas a una Página maestra ASP.NET (default.master) que implementa un diseño común para los menús y controles de navegación. Default.master reside en la carpeta C:\Archivos de programa\Archivos comunes\Microsoft Shared\Web Server Extensions\12\Template\Global e incluye marcadores de posición con nombre para páginas de contenido adicionales que también pueden residir en el sistema de archivos local o en una base de datos de contenido de SQL Server. El aspecto clave es que al abrir un sitio de SharePoint en un explorador web, lo que está viendo, realmente, es información de una colección de páginas de contenido que no se encuentran, necesariamente, ubicadas en el servidor web local y que se distribuyen de acuerdo a un diseño definido en una Página maestra.
La regla general es que las páginas no modificadas (o páginas no personalizadas según la terminología de SharePoint) existen como plantillas de página en el sistema de archivos local de cada servidor de SharePoint, mientras que las páginas personalizadas se escriben en la base de datos de contenido de modo que todos los servidores SharePoint en una granja de servidores web obtengan acceso al mismo conjunto de páginas (consulte la Figura 3). Asumimos que las páginas no personalizadas son idénticas en todos los servidores y sitios de la granja de servidores web. Sin embargo, si personaliza una página de contenido o una Página maestra en un sitio de SharePoint, usando, por ejemplo, Office SharePoint Designer 2007, SharePoint almacena automáticamente la página personalizada en la base de datos de contenido.
Figura 3** Páginas no personalizadas y personalizadas de ASP.NET en una aplicación SharePoint **(Hacer clic en la imagen para ampliarla)
Además de páginas personalizadas y otros contenidos de sitio web, SharePoint almacena también datos de configuración en una base de datos de SQL Server. SharePoint mantiene los datos de configuración separados del contenido porque los datos de configuración son globales por naturaleza, mientras que el contenido es específico de cada aplicación web individual y colección de sitios. Por consiguiente, una granja de servidores web sólo puede tener una base de datos de configuración, pero puede tener varias bases de datos de contenido.
Todos los servidores WSS en la granja de servidores web usan la misma base de datos de configuración para compartir los metadatos, las opciones de configuración y la información acerca de cada uno de los sitios web de IIS que se han extendido a SharePoint en la granja de servidores web. Las aplicaciones web individuales, por otro lado, pueden asociarse con una o más bases de datos de contenido (aunque cada una de las bases de datos de contenido sólo se puede asociar con una aplicación web).
La relación entre los sitios web de IIS, las aplicaciones web, las colecciones de sitios, los sitios y las bases de datos de contenido puede ser muy confusa. En la terminología de SharePoint, el término aplicación web se refiere a un sitio web de IIS extendido de SharePoint. Una aplicación web puede incluir varias colecciones de sitios y cada una de estas colecciones de sitios puede, a su vez, incluir un sitio de nivel superior y sitios de nivel inferior que comparten las mismas opciones de configuración.
Entre otras cosas, la creación de varias colecciones de sitios le permite delegar la administración de la colección de sitios a usuarios y grupos diferentes. Una única colección de sitios no puede abarcar varias bases de datos de contenido, pero una aplicación web puede usar varias bases de datos de contenido para varias colecciones de sitios y de este modo incrementar la escalabilidad y mitigar la repercusión en el rendimiento de un sitio de gran tamaño que genera una cantidad considerable de actividad de la base de datos en otros sitios de SharePoint. Sin embargo, no es buena idea el ubicar cada uno de los sitios de SharePoint en su propia colección de sitios porque esta forma de implementación limita la funcionalidad entre los sitios.
WSS 3.0 no es compatible con las búsquedas de contenido en varias colecciones de sitios. Dichas búsquedas requieren MOSS 2007 o Microsoft Search Server 2008. Por ejemplo, puede crear una aplicación web y un sitio de nivel superior para http://contoso y, a continuación, un administrador de colección de sitios puede crear sitios de nivel inferior mediante la interfaz de usuario de SharePoint como, por ejemplo, http://contoso/info y http://contoso/events. Todo estos sitios existen en la misma base de datos de contenido puesto que pertenecen a la misma colección de sitios.
Como administrador de una granja de servidores, puede usar, igualmente, una ruta de acceso administrada como, por ejemplo, /sites y, a continuación, definir colecciones de sitios adicionales tales como http://contoso/sites/IT y http://contoso/sites/HR, en la Administración central de SharePoint 3.0. Estas tres colecciones de sitios (http://contoso, http://contoso/sites/IT y http://contoso/sites/HR) pueden tener administradores de colecciones de sitios, opciones de configuración y bases de datos de contenido muy diferentes, sin embargo el acceso a todas ellas se realiza a través del mismo sitio web de IIS (http://contoso) y todas ellas usan la misma identidad del grupo de aplicaciones de la aplicación web.
Por supuesto, hay muchos más detalles, no obstante, la comprensión de esta relación entre IIS, ASP.NET y SQL Server es especialmente importante para sentirse cómodo con el funcionamiento de SharePoint. Si está interesado en conocer más detalles de la arquitectura de SharePoint, le recomiendo la lectura del artículo escrito por Ted Pattison en MSDN® Magazine titulado "Detección de mejoras significativas de desarrollador en SharePoint Services" y que está disponible en msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview.
Elementos de la infraestructura de SharePoint
Convirtamos ahora este breve debate acerca de la arquitectura en una infraestructura flexible de SharePoint. Como probablemente haya advertido, necesitamos Windows Server®, IIS, .NET Framework 3.0 (ambos para ASP.NET y Windows® Workflow Foundation), WSS 3.0 o MOSS 2007 y SQL Server. Aunque puede esperar al lanzamiento de IIS 7.0 en Windows Server 2008, en este caso usaremos IIS 6.0 en Windows Server 2003 para nuestros fines, puesto que en el momento en el cual se ha escrito este artículo se trata de la versión más ampliamente implementada. Nos quedaremos con WSS 3.0 ya que no necesitamos las características específicas de MOSS 2007 para un piloto inicial de SharePoint.
Si desea un enfoque minimalista, puede instalar WSS 3.0 con todos los componentes necesarios en un único equipo (tal y como se describe en WSS 3.0 en un único computer.pdf, disponible en el material complementario de esta columna), esto es suficiente para un servidor de laboratorio o un entorno de grupo de trabajo pequeño. Sin embargo, si piensa centrarse en la flexibilidad en su infraestructura de SharePoint, no debe comenzar con una implementación independiente en su entorno de producción. Con el objeto de favorecer la disponibilidad, así como la futura escalabilidad, es preferible comenzar con una infraestructura de varios niveles y agregar más servidores cuando sea necesario.
La Figura 4 muestra la infraestructura de SharePoint que recomiendo si desea conseguir una configuración de sistema sencilla y flexible. Incluye una granja de servidores web de dos servidores SharePoint y un equipo independiente que ejecuta SQL Server. Esta configuración elimina la sobrecarga de procesamiento de base de datos en los servidores web, incrementa la disponibilidad, la escalabilidad y facilita el mantenimiento del sistema. Tenga en cuenta que Active Directory® es necesario puesto que se trata de un requisito de software de WSS 3.0 en una implementación de granja de servidores web. Para obtener las instrucciones de implementación paso a paso, consulte el archivo Basic SharePoint Infrastructure.pdf en el material complementario.
Figura 4** Infraestructura básica de SharePoint que puede adaptarse a un crecimiento futuro **(Hacer clic en la imagen para ampliarla)
La cuenta de dominio usada para implementar SharePoint en esta disposición requiere los permisos de un administrador local en los servidores web. Es también necesario agregar esta cuenta a las funciones dbcreator y securityadmin de SQL Server así como a la función de base de datos db_owner de la base de datos maestra en SQL Server 2005, tal como se muestra en el archivo Basic SharePoint Infrastructure.pdf. A continuación, puede usar el Asistente para configuración de Productos y Tecnologías de SharePoint durante la instalación de WSS 3.0 para crear la base de datos de configuración, necesaria para la granja de servidores web y una base de datos de contenido para el sitio de Administración central de SharePoint 3.0. De lo contrario, un administrador de SQL Server debe encargarse de aprovisionar estas bases de datos y de agregar las cuentas del sistema de WSS a la función db_owner.
Es importante tener presente que la cuenta de usuario que usa para instalar SharePoint no es la cuenta que usa SharePoint para obtener acceso a la base de datos de configuración o a la base de datos de contenido del sitio de Administración central. En su lugar, SharePoint usa la cuenta del sistema configurada como la identidad del grupo de aplicaciones para el sitio de Administración central de SharePoint 3.0.
El Asistente para configuración de Productos y Tecnologías de SharePoint le solicitará la información de la cuenta. Es una buena idea usar una cuenta de usuario de dominio dedicada para esto como, por ejemplo, CONTOSO\WssConfigAdmin. Mi práctica general ha consistido en usar cuentas de usuario individuales y dedicadas para cualquier aplicación web adicional que cree posteriormente. El uso de un grupo de aplicaciones independiente para cada aplicación web ayuda a garantizar el aislamiento del proceso y el uso de una cuenta de usuario diferente para cada grupo de aplicaciones ayuda a mantener el aislamiento de la seguridad. Debe tenerse en cuenta, no obstante, que esto es sólo un enfoque y que la capacidad de administración y las repercusiones potenciales que pueda tener en el rendimiento deben evaluarse según los requisitos particulares de entorno y de negocio.
El administrador de dominio debe encargarse, asimismo, de crear otra cuenta del sistema muy importante, la cuenta del servicio de búsqueda. Puede usar la cuenta de Administración central, no obstante, para conseguir una seguridad adicional es mejor usar una cuenta de búsqueda dedicada, como CONTOSO\WssSearch, que no tenga permisos administrativos y que no pueda modificar ningún contenido. No es necesario un permiso de escritura para obtener acceso a las bases de datos de contenido puesto que el Servicio de búsqueda sólo rastrea el contenido con el objeto de llevar a cabo su indización y mantiene los datos de la búsqueda en una base de datos independiente.
Al crear una aplicación web en una granja de servidores, puede asociar esa base de datos de contenido a un servidor de búsqueda, lo que agrega implícitamente la cuenta del servicio de búsqueda correspondiente a la directiva Acceso completo de lectura de la aplicación web. Los servidores de búsqueda son servidores SharePoint que ejecutan el servicio de búsqueda de Windows SharePoint Services. Si siguió las instrucciones paso a paso del archivo Basic SharePoint Infrastructure.pdf, habrá configurado ambos servidores web como servidores de búsqueda de modo que pueda distribuir la carga de rastreo e indización de varias bases de datos de contenido. Sin embargo, es también posible configurar un servidor de búsqueda dedicado en una granja de servidores web, excluido del equilibrio de carga de red y de las conexiones del cliente de manera que éstas últimas no se vean afectadas por las actividades de rastreo.
Administración de sitios sin intervención del administrador
Con una infraestructura básica de SharePoint implementada, podemos delegar la administración de las colecciones de sitio y de los sitios a departamentos y usuarios individuales sin descentralizar el control administrativo sobre Active Directory, la granja de servidores web o las bases de datos de SQL Server. Como administrador de la granja de servidores, debe colaborar con los administradores de Active Directory y SQL Server para aprovisionar las cuentas del grupo de aplicaciones y las bases de datos de contenido para sus aplicaciones web. Dentro de estas aplicaciones web, debe crear, a continuación, colecciones de sitios y designar administradores de la colección de sitios con el derecho de crear sitios de nivel inferior. De este modo, los administradores de colecciones de sitios dentro de departamentos individuales pueden administrar sus recursos de SharePoint con la participación mínima del departamento de TI, tal como se muestra en la Figura 5.
Figura 5** Administración descentralizada del sitio en una infraestructura de SharePoint centralizada **(Hacer clic en la imagen para ampliarla)
Es también posible ofrecer a los usuarios la capacidad de crear colecciones de sitios bajo rutas de acceso administradas (como la ruta de acceso /sites u otras rutas administradas con inclusiones de caracteres comodín que cree en la Administración central de SharePoint 3.0). Si habilita la característica Administración de sitios sin intervención del administrador dentro de una aplicación web, los usuarios pueden crear sus propias colecciones de sitios y administrar grupos de sitio y permisos dentro de la interfaz de usuario de SharePoint. A diferencia de los sitios de nivel inferior, las colecciones de sitios no heredan los permisos de un sitio primario.
La Administración de sitios sin intervención del administrador no es apropiada para todo entorno de SharePoint y se deshabilita de forma predeterminada. Si la habilita, puede que al final termine con un gran número de colecciones de sitios que no se utilicen muy a menudo en sus bases de datos de contenido. Sin embargo, esta característica demuestra, de forma exhaustiva, la flexibilidad de la administración de SharePoint y le recomiendo, por tanto, que la pruebe en su implementación piloto. (Además, existen opciones en SharePoint para notificar a usuarios y/o administradores acerca de los sitios inactivos para que éstos puedan eliminarse en caso de ser necesario). Debe habilitar la Administración de sitios sin intervención del administrador para una aplicación web de forma explícita, tal como se describe en el archivo Enabling Self-Service Site Management.pdf que se incluye en el material complementario.
Personalizaciones y personalización de marca de SharePoint
Recursos de SharePoint
- TechCenter de Windows SharePoint Services
- Centro de desarrollo de Windows SharePoint Services
- Blog del equipo de Productos y Tecnologías de Microsoft SharePoint
- Componentes de la arquitectura lógica
- Diseño de granjas de servidores y topologías
En este momento, constituye un deseo natural el incluir el logotipo de la empresa, el nombre y los colores corporativos en la interfaz de usuario de SharePoint. No obstante, debe estar atento al hecho de que está a punto de elevar el proyecto de SharePoint al nivel de desarrollador de ASP.NET. Como mínimo, necesita un sistema de desarrollo como, por ejemplo, un servidor WSS 3.0 independiente con Microsoft Office SharePoint Designer 2007 (consulte el archivo SharePoint Designer Installation.pdf del material complementario) para poder crear y probar sus personalizaciones sin afectar al entorno de producción. Asimismo, debe visitar el Centro de desarrollo de Windows SharePoint Services en msdn2.microsoft.com/sharepoint para conocer más detalles acerca de las opciones de personalización que ofrece SharePoint.
Aunque el desarrollo de SharePoint queda fuera del alcance de esta columna, déjeme señalar una serie de aspectos que debe tener en cuenta. SharePoint almacena páginas personalizadas en la base de datos de contenido de la colección de sitios correspondiente. En otras palabras, cualquier personalización que aplique a las páginas del sitio, páginas de la aplicación, Páginas maestras, hojas de estilos, etc., en un sitio de SharePoint sólo se aplica a la colección de sitios o al nivel del sitio. Esto es de gran ayuda de cara a los administradores de colecciones de sitios individuales que desean ajustar la apariencia de sus sitios mediante SharePoint Designer 2007, pero no lo es, sin embargo, para el administrador de la granja de servidores que desea imponer la identidad corporativa en todas aplicaciones web, las colecciones de sitios y los sitios en una granja de servidores web.
Puede crear temas del sitio personalizados o definiciones del sitio personalizadas según una copia de un tema o definición de sitio estándar de SharePoint. Puede crear, asimismo, Páginas maestras personalizadas y agregarlas a la Galería de páginas maestras. Sin embargo, ninguna de estas opciones impone la personalización de marca global si está habilitada la Administración de sitios sin intervención del administrador, ya que un usuario con permisos para crear colecciones de sitios o sitios puede, aún, seleccionar una plantilla de sitio estándar que no muestre la identidad corporativa.
La personalización de marca global exige el reemplazo por su parte de los componentes predeterminados de SharePoint y el uso, en su lugar, de sus componentes personalizados. Los desarrolladores hacen todo lo posible para conseguir esto sin modificar los archivos originales. Uno de los enfoques consiste en cambiar la configuración de los directorios virtuales en el Administrador de IIS para apuntarlos a nuevas carpetas con archivos personalizados. Otro método consiste en implementar un módulo HTTP personalizado o el filtro ISAPI que rescribe direcciones URL para redirigir las solicitudes de páginas predeterminadas específicas a versiones personalizadas.
Conclusión
Me he centrado en los aspectos básicos del establecimiento de una infraestructura de SharePoint con WSS 3.0. No he tratado otras características como, por ejemplo, los flujos de trabajo, las encuestas, la integración de la mensajería o los antivirus, ni tampoco funcionalidades específicas de MOSS 2007 como portales, directorios de sitios y catálogos de datos profesionales. Las personalizaciones de la administración de sitios y la personalización de marca de las compañías sólo se tratan como posibilidades dentro de SharePoint. Puede llevar a cabo personalizaciones adicionales con WSS 3.0 programando las aplicaciones personalizadas en Visual Studio®.
La infraestructura es lo suficientemente eficaz para administrar el crecimiento futuro si agrega más servidores web o servidores de base de datos. Con el lanzamiento piloto de una serie de personalizaciones, los usuarios podrán crear sitios individuales y familiarizarse a nivel general con SharePoint. De este modo, usted establece los componentes principales que adoptará el usuario, así como el hardware y el software, que serán lo suficientemente flexibles como para poder acomodar los cambios y servir de base para un avanzado lanzamiento de producción.
Pav Cherny es experto en TI y autor especializado en tecnologías de Microsoft para la colaboración y las comunicaciones unificadas. Sus publicaciones incluyen notas del producto, manuales de productos y libros centrados en operaciones de TI y administración de sistemas. Pav es el Presidente de Biblioso Corporation.
© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.