WSS 3.0 & MOSS: Algunos tips de implementación y administración (I)!

Cómo sabéis, la gestión adecuada de soluciones SharePoint pasa por realizar una implementación adecuada de las mismas, y por supuesto las correspondientes laboras de administración, todo ello regado por la aplicación de las correspondientes buenas prácticas. Ahora bien, como sucede cuando desarrollamos, configuramos un producto o servidor o probamos una tecnología, nos encontramos con una serie de trucos que nos facilitan la administración e implementación de soluciones SharePoint. Empecemos.

Sobre Application Pools e implementaciones SharePoint

Las recomendaciones a la hora de crear web applications de SharePoint son:

  • No ejecutar más de 10 web applications de SharePoint en un mismo Application Pool de IIS para evitar posibles problemas de rendimiento. Evidentemente siempre tenemos la opción de añadirle más memoria al servidor para superar estos posibles problemas.
  • No ejecutar más de 20 web applications de SharePoint en un mismo frontal web (de nuevo para evitar problemas de rendimiento y escalabilidad). Se recomienda añadir un segundo frontal a la granja.
  • Para tener flexibilidad máxima a la hora de asignar recursos a los application pools, se recomienda que el frontal web tenga un mínimo de 4 GB de RAM.

image

Sobre configuración de seguridad

SharePoint permite dos mecanismos de autenticación al crear una web application:

  • Kerberos, es el mecanismo más seguro, pero requiere un SPN (Service Principal Name) para la cuenta de dominio que SharePoint está utilizando. Más información en: http://support.microsoft.com/?id=832769
  • NTLM, dónde no importa la cuenta de dominio que se esté usando a nivel de web application para comunicarse con el Application Pool correspondiente puesto que este tiene los permisos necesarios para acceder a SQL Server (roles Database Creator y Security Administrator).

image image

Configuración de los Application Pool

El paso clave a la hora de crear una web application, es asignarle un Application Pool. Normalmente crearemos un Application Pool por web application teniendo en cuenta las recomendaciones comentadas con anterioridad. Una vez creado este Application Pool, hay que elegir la cuenta de seguridad que va a usar. Básicamente, podemos utilizar una cuenta local o de servicio de red, o bien crear y asignar una nueva. Las opciones por tanto son:

  • Utilizar la cuenta Local Service, que se caracteriza por tener privilegios mínimos en el servidor. Esta cuenta es útil cuando no necesitemos conectarnos a recursos en equipos remotos. Además, esta cuenta resulta adecuada sólo en escenarios de instalación tipo standalone.
  • Utilizar la cuenta Network Service, que es similar a la anterior, pero con la capacidad de conectarse a equipos remotos.
  • Utilizar una cuenta configurable, lo que nos permite asignar una cuenta de dominio que hayamos creado como cuenta de servicio para que el Application Pool pueda acceder a los servicios y servidores requeridos (como SQL Server). Esta cuenta la deberíamos crear siguiendo una serie de pautas:
    • Nombre con formato dominio\nombre usuario.
    • Administrador local en el servidor de SharePoint.
    • Roles Database Creator y Security Administrator en la BD SQL Server.

Bases de datos de contenidos

Una Web Application de SharePoint se puede asociar con múltiples bases de datos de contenidos. La BD que por defecto se crea en el momento de creación de una Web Application puede contener hasta 15.000 colecciones de sitios.

image

Y hasta aquí llega este primer post sobre tips de implementación y administración en SharePoint.

WSS 3.0 & MOSS: Algunos tips de implementación y administración (I)!

Cómo sabéis, la gestión adecuada de soluciones SharePoint pasa por realizar una implementación adecuada de las mismas, y por supuesto las correspondientes laboras de administración, todo ello regado por la aplicación de las correspondientes buenas prácticas. Ahora bien, como sucede cuando desarrollamos, configuramos un producto o servidor o probamos una tecnología, nos encontramos con una serie de trucos que nos facilitan la administración e implementación de soluciones SharePoint. Empecemos.

Sobre Application Pools e implementaciones SharePoint

Las recomendaciones a la hora de crear web applications de SharePoint son:

  • No ejecutar más de 10 web applications de SharePoint en un mismo Application Pool de IIS para evitar posibles problemas de rendimiento. Evidentemente siempre tenemos la opción de añadirle más memoria al servidor para superar estos posibles problemas.
  • No ejecutar más de 20 web applications de SharePoint en un mismo frontal web (de nuevo para evitar problemas de rendimiento y escalabilidad). Se recomienda añadir un segundo frontal a la granja.
  • Para tener flexibilidad máxima a la hora de asignar recursos a los application pools, se recomienda que el frontal web tenga un mínimo de 4 GB de RAM.

image

Sobre configuración de seguridad

SharePoint permite dos mecanismos de autenticación al crear una web application:

  • Kerberos, es el mecanismo más seguro, pero requiere un SPN (Service Principal Name) para la cuenta de dominio que SharePoint está utilizando. Más información en: http://support.microsoft.com/?id=832769
  • NTLM, dónde no importa la cuenta de dominio que se esté usando a nivel de web application para comunicarse con el Application Pool correspondiente puesto que este tiene los permisos necesarios para acceder a SQL Server (roles Database Creator y Security Administrator).

image image

Configuración de los Application Pool

El paso clave a la hora de crear una web application, es asignarle un Application Pool. Normalmente crearemos un Application Pool por web application teniendo en cuenta las recomendaciones comentadas con anterioridad. Una vez creado este Application Pool, hay que elegir la cuenta de seguridad que va a usar. Básicamente, podemos utilizar una cuenta local o de servicio de red, o bien crear y asignar una nueva. Las opciones por tanto son:

  • Utilizar la cuenta Local Service, que se caracteriza por tener privilegios mínimos en el servidor. Esta cuenta es útil cuando no necesitemos conectarnos a recursos en equipos remotos. Además, esta cuenta resulta adecuada sólo en escenarios de instalación tipo standalone.
  • Utilizar la cuenta Network Service, que es similar a la anterior, pero con la capacidad de conectarse a equipos remotos.
  • Utilizar una cuenta configurable, lo que nos permite asignar una cuenta de dominio que hayamos creado como cuenta de servicio para que el Application Pool pueda acceder a los servicios y servidores requeridos (como SQL Server). Esta cuenta la deberíamos crear siguiendo una serie de pautas:
    • Nombre con formato dominio\nombre usuario.
    • Administrador local en el servidor de SharePoint.
    • Roles Database Creator y Security Administrator en la BD SQL Server.

Bases de datos de contenidos

Una Web Application de SharePoint se puede asociar con múltiples bases de datos de contenidos. La BD que por defecto se crea en el momento de creación de una Web Application puede contener hasta 15.000 colecciones de sitios.

image

Y hasta aquí llega este primer post sobre tips de implementación y administración en SharePoint.

Windows Azure: WhitePapers sobre .NET Services!

Cómo sabéis, uno de los componentes clave de la plataforma Windows Azure son los .NET Services. Pues bien, Microsoft acaba de publicar una serie de WhitePapers que nos permitirán entender mejor estos servicios desde el punto de vista del desarrollo. El detalle de los WhitePaper, que podéis descargar a través de este enlace, es el siguiente:

  • An Introduction to Microsoft .NET Services for Developers. This overview paper introduces Microsoft® .NET Services, each of its building block services, and how they fit together.
  • A Developer’s Guide to the Microsoft® .NET Access Control Service. This whitepaper shows developers how to use a claims-based identity model and the Microsoft® .NET Access Control Service – part of the Microsoft® .NET Services family – to implement single sign-on, federated identity, and role based access control in Web applications and services.
  • A Developer’s Guide to the Microsoft® .NET Service Bus. This whitepaper shows developers how to use the .NET Service Bus – part of the Microsoft® .NET Services family – to provide a secure, standards-based messaging fabric to connect applications across the Internet.
  • A Developer’s Guide to the Microsoft® .NET Workflow Service. This whitepaper provides details about the Microsoft® .NET Workflow Service, its relation to Windows Workflow Foundation, and what developers need to know to begin building workflows for the cloud. It not only explains the current tools and capabilities but also outlines the vision for future releases.

image