Este artículo proviene de un motor de traducción automática.

Tomar el control

Usar SharePoint para administrar los servicios de Windows

Pav Cherny

Descarga de código de la Galería de código de MSDN
Examinar el código en línea

Contenido

Un prototipo de solución no integrado
Integración con SharePoint
Definir proceso de identidades
Las dependencias del servicio de Windows
Agregar parámetros de configuración
Pruebas y toque final
Sumar hacia arriba

Todos los sistemas operativos de Windows Server dependen mucho en los servicios de Windows.Esto no ha cambiado ya que Microsoft introdujo primero servicios con Microsoft Windows NT 3.1 en 1993 y es probable que no se modificará en futuras sistemas operativos o bien.No puede existir SharePoint incluso sin servicios de Windows, como Internet Information Services (IIS) y servicios adicionales de las tareas específicas de SharePoint.Puede sacar partido de la infraestructura de servicios integrados a través de trabajos personalizados para el servicio de temporizador de Windows SharePoint Services (SPTimerV3), pero si desea una amplia procesamiento de datos, supervisión sistema continuo, detección de virus, comunicación o copia de seguridad en función de agente de red y restaurar las operaciones, es aún mejor crear sus propios servicios de Windows independientes.No es difícil de crear un servicio de Windows.Visual Studio 2008 incluye las plantillas de proyecto es necesario y asistentes para obtener iniciado y pueden utilizar C/C ++, así como idiomas administradas para implementar la lógica del servicio.Sin embargo, no es tan sencillo integrar un servicio de Windows con SharePoint.El Kit de desarrollo de Windows SharePoint Services (WSS) 3.0 software (SDK) no cubre este tema muy bien, no hay asistentes y debe asegurarse de que los resultados de integración no debe poner empleadas seguridad de SharePoint.

En este artículo, mostraré cómo integrar una solución de services–based Windows con SharePoint.Los resultados permiten aprovisionar, iniciar, detener y quitar instancias de servicio a través de administración central de SharePoint 3.0 y el modelo de objetos de administración de SharePoint, mantener configuraciones de servicio de forma centralizada en la base de datos de configuración de SharePoint y asegurarse de que todas instancias de servicio en un conjunto de servidores de SharePoint usan los mismos parámetros de cuenta y la configuración de seguridad.Al cambiar la configuración de SharePoint, puede aplicar los cambios coherente en todos los servidores en el conjunto de servidores.Por supuesto, también es posible configurar parámetros por separado para instancias de servicios individuales, si es necesario.Para la solución de ejemplo, decidió realizar una operación confidencial en servidores para resaltar las consideraciones de seguridad específica de SharePoint.El material complementario incluye código fuente y compila los archivos en distintas fases de finalización según a la secuencia de pasos que abordaré aquí.El material complementario también incluye las hojas de cálculo paso a paso si desea seguir mi explicación en su propio entorno de desarrollo.

Un prototipo de solución no integrado

Es una mejor práctica para comenzar un ciclo de desarrollo a recopilar los requisitos, presenta un diseño de solución general y entrega de prueba de concepto en forma de un prototipo representativo.Esto es especialmente cierto para servicios de SharePoint confidenciales de seguridad que requieren permisos elevados en los servidores de solicitudes de cliente o servidores de aplicaciones.Aunque no es necesario integrar el prototipo con SharePoint para facilitar la administración, el prototipo debe ocuparse de las dependencias de seguridad de SharePoint directamente desde el principio para evitar problemas de diseño complejos más adelante.Incluso aparentemente soluciones sencillas es posible que plantean desafíos complicados en un entorno de SharePoint.

Tomemos solución de ejemplo en este artículo, por ejemplo.Trata el requisito para consolidar las entradas del seguridad de registro de eventos de servidores front-end de una lista de SharePoint personalizada.Es una tarea aparentemente simple: la solución registra un controlador denominado EntryWrittenEventHandler en el subsistema del registro de eventos en el equipo local para recibir una notificación de evento cuando el sistema operativo agrega una nueva entrada para el registro de sucesos de seguridad y, a continuación, si la entrada cumple un criterio de filtro especificada, como tipo de entrada es igual a FailureAudit o SuccessAudit, la solución agrega un elemento correspondiente a una lista personalizada de auditoría de seguridad en SharePoint.No es difícil de crear un servicio básico de Windows y una lista de SharePoint personalizada para ello, pero la cuenta del servicio requiere permisos de escritura en el sitio de SharePoint para agregar elementos a la lista personalizada y permisos administrativos en el servidor local para registrar EntryWrittenEventHandler, y éste es un problema de seguridad en servidores de SharePoint.

Mientras que puede satisfacer los requisitos de permisos de SharePoint ejecutando el servicio de Windows en el contexto de grupo de aplicación cuenta del sitio de SharePoint, no debe conceder permisos administrativos locales a las cuentas de seguridad de SharePoint.Conceder seguridad cuentas permisos administrativos en los servidores de solicitudes de cliente jeopardizes seguridad de SharePoint, como se explicó en la columna enero de 2009 TechNet Magazine titulada"Cuentas de seguridad de SharePoint."

¿Por lo tanto, cómo evitar la elevación de permisos si la solución debe realizar una operación de seguridad confidencial?Una buena técnica es dividir la solución en varios componentes y utilizar un mecanismo de comunicación entre procesos segura entre ellos.A continuación, se puede ejecutar el componente que requiere permisos administrativos en el contexto de la cuenta del sistema local, mientras que el otro componente se ejecuta en el contexto de la cuenta de seguridad de SharePoint.Microsoft utiliza esta técnica en el servicio SPTimerV3.SPTimerV3 se ejecuta sin permisos administrativos en el contexto de la cuenta de conjunto de servidores de SharePoint y se basa en el servicio de administración de servicios de Windows SharePoint (SPAdmin) para realizar tareas administrativas en el servidor local.El servicio SPAdmin se ejecuta en el contexto de la cuenta Sistema local.SPTimerV3 y SPAdmin utilizan .NET Remoting para la comunicación entre procesos, pero también puede utilizar un mecanismo de peso más claro, como canalizaciones con nombre, siempre que se protege la utilidad de comunicación de por medio listas de control de acceso (ACL).En la solución de ejemplo, uso el enfoque de canalización con nombre.

Eche un vistazo a la arquitectura general de la solución en la figura 1 .La solución depende de un servicio de controlador de eventos de seguridad independiente que incluya la función de devolución de llamada EntryWrittenEventHandler mencionados anteriormente para recibir notificaciones del subsistema del registro de eventos local de.Este servicio se ejecuta en el contexto de la cuenta Sistema local.Su homólogo es el servicio receptor de eventos de seguridad, que se ejecuta en el contexto de cuenta de grupo de aplicación del sitio de SharePoint para crear elementos de contenido en una lista de auditoría de seguridad especificado.Cuando se inicia el receptor de eventos de seguridad, el servicio crea una canalización con nombre segura que concede sólo el local System cuenta permisos de acceso.El servicio de controlador de eventos de seguridad utiliza esta canalización con nombre cuando se desencadena un evento "seguridad escritura de entrada de registro de eventos" para comunicarse con el receptor de eventos de seguridad.Este diseño funciona sin los requisitos de permisos elevados y sin jeopardizing seguridad de SharePoint.Es sólo un poco más complicada que la arquitectura de servicio monolítica típica de Windows.

Figura 1 Dividir hacia arriba una solución de SharePoint

Puede que observe en la aplicación de ejemplo que Microsoft .NET Framework no puede analizar la descripción de las entradas de seguridad.Esto no es crítico para el propósito de este artículo, pero considere instalar la revisión descrita en el artículo de Microsoft Knowledge Base"Una aplicación que utiliza el registro de sucesos de seguridad de las API de Windows NT no puede leer la descripción de un mensaje de registro de eventos desde un equipo que está ejecutando Windows Vista o Windows Server 2008."

Integración con SharePoint

La entrega de un prototipo funcional es un hito importante; otra es ofrecer herramientas de administración adecuadas y este es un aspecto clave de integración de SharePoint para los servicios de Windows.Sin integración, es difícil de controlar las instancias de servicio implementado o garantizar un comportamiento del servicio coherente entre todos los servidores de un conjunto de servidores.Con la integración, puede utilizar Administración central de SharePoint 3.0 para determinar los servidores que ejecutan los servicios y configurar parámetros relevantes para todas las instancias de servicio de forma centralizada.la figura 2 muestra la aplicación una vez que haya finalizado todos los pasos de integración.Aspecto una pequeña aplicación, pero integración de SharePoint, ofrece todas las características de una solución completa de SharePoint.

La Figura 2 Integración con SharePoint

Básicamente, tiene cuatro componentes para integrar un servicio de Windows con SharePoint: una clase que identifica el servicio, una clase que permite que SharePoint controlar cada servicio instancias, una herramienta administrativa que agrega los objetos de estas dos clases a la configuración de SharePoint y un paquete de solución de SharePoint para implementar estos componentes.

Según la arquitectura de soluciones muestra en la figura 1 , hay dos servicios de Windows: controlador de eventos de seguridad y el receptor de eventos de seguridad.Por lo que vamos a crear las clases de servicio correspondiente en un nuevo proyecto de biblioteca de clases.Este proyecto agregarlo directamente a la solución de SecurityAudit que ha integrada en Visual Studio.Se denomina SecurityEventManagement.Después de que había agregado una referencia a la biblioteca Windows SharePoint Services, crea una nueva clase derivada de la clase de SPWindowsService para cada servicio de Windows.En la implementación inicial de la clase SecurityEventReceiverService, la clase SecurityEventHandlerService tiene la misma estructura; sólo el nombre del servicio es diferente, como se ver si analizar el código en la carpeta paso 2 en el material complementario.

La clase de servicio representa un determinado servicio de Windows en un conjunto de servidores de SharePoint.Es un objeto global para todas las instancias de servicio, pero también necesita una clase para asociar una instancia del servicio a un determinado servidor de SharePoint.El modelo de objetos de administración de SharePoint define varias clases de base de servicio y las clases de instancia de servicio al que se corresponden.La clase SPWindowsService es la elección correcta para los servicios de Windows, y, por tanto, la clase SPWindowsServiceInstance es la clase base hacia la derecha para las clases de instancia de servicio: SecurityEventReceiverServiceInstance y SecurityEventHandlerServiceInstance.De nuevo, las definiciones de clase son relativamente uncomplicated.

Ahora me permite mostrar cómo crear la herramienta administrativa para agregar el servicio y objetos de la instancia de servicio a la configuración de SharePoint.Puede hacerlo mediante páginas de aplicación de administración central de SharePoint 3.0, las extensiones de comandos Stsadm.exe, ni por ningún otro medio, como a través del uso de Windows PowerShell.Decidido para crear una extensión de comandos Stsadm.exe debido a su baja sobrecarga, lo que significa distracción poco de at hand el trabajo.Para detallada información sobre las extensiones de comando Stsadm.exe, consulte el artículo"Cómo: Extender la utilidad STSADM."

La herramienta administrativa debe crear una instancia y conservar el servicio y objetos de la instancia de servicio.Los constructores de las clases de mostrar cómo crear instancias de los objetos.Es importante que las clases de servicio de SharePoint se derivan de la clase SPPersistedObject.Cuando se llama al método Update(), estos objetos se conservan.De forma similar, si se llama al método Delete() después de-provisioning, estos objetos se quitan nuevo.El archivo de código SecurityEventServiceAdministration.cs en el proyecto de SecurityEventManagement ilustra estos pasos.

Y eso es todo!Ahora puede compilar la solución y distribuirlo a través del uso de un paquete de solución de WSS 3.0 (.wsp).Para obtener una explicación detallada de cómo crear un paquete de solución con Visual Studio y MakeCab.exe, se recomiendaArtículo Andrew Connellacerca de cómo crear archivos de solución WSS.Vea también el código en el material complementario.

Definir proceso de identidades

La sencillez de integración de SharePoint puede ser una sorpresa interesante, pero es un resultado directo de tener aprovechado completa el modelo de objetos de SharePoint.Ya puede crear instancias de servicio y utilizar los vínculos de administración en Administración central de SharePoint 3.0 (consulte la figura 3 ).Por ejemplo, puede iniciar y detener el servicio de receptor de eventos de seguridad; sólo el servicio de controlador de eventos de seguridad no es tan fácil.Esto es así porque SharePoint actualiza la configuración del servicio cuando se haga clic en el vínculo Iniciar.De forma predeterminada, SharePoint configura el servicio para ejecutarse en el contexto de la cuenta Servicio local, que no tiene permisos para registrar un EntryWrittenEventHandler.Por lo tanto, el servicio de controlador de eventos de seguridad no se.Deberá hardwire el servicio de controlador de eventos de seguridad para la cuenta Sistema local y debe proporcionar una opción para aprovisionar el servicio de receptor de eventos de seguridad con una cuenta de grupo de aplicación que desee.

La figura 3 Administración central de SharePoint 3.0

Comencemos con el servicio de controlador de eventos de seguridad ya que es sencillo hardwire la cuenta del sistema.Sólo, requieren tres líneas de código de en el constructor de servicio.La primera línea establece la identidad del proceso del servicio en la cuenta del sistema.Las otras dos líneas deshabilite las implementaciones de credenciales y credenciales de actualizaciones para impedir que los administradores puedan realizar cambios a la información de cuenta de administración central de SharePoint 3.0.La página de cuentas de servicio (_admin/FarmCredentialManagement.aspx) ya no muestra este servicio en el cuadro de lista de servicio de Windows.

public SecurityEventHandlerService(SPFarm spFarm)
       : base(ntServiceName, spFarm)
{
   base.ProcessIdentity.CurrentIdentityType = IdentityType.LocalSystem;
   base.ProcessIdentity.IsCredentialDeploymentEnabled = false;
   base.ProcessIdentity.IsCredentialUpdateEnabled = false;
}

El servicio de receptor de eventos de seguridad es un poco más complicado porque debe controlar una variedad de información de cuenta de seguridad durante el aprovisionamiento de servicio. La cuenta de seguridad puede ser una cuenta de usuario de dominio con una contraseña o una cuenta de sistema sin una contraseña. Al solucionar con una cuenta de usuario de dominio, el nombre de la cuenta debe siguen las convenciones de nombre NetBIOS y debe comprobar la contraseña. En mi implementación, el código establece las propiedades IsCredentialDeploymentEnabled y IsCredentialUpdateEnabled de esta clase en true para que los administradores de SharePoint pueden cambiar la cuenta de seguridad en Administración central de SharePoint 3.0 después el servicio del receptor de eventos de seguridad de aprovisionamiento.

Por supuesto, también debe ampliar la herramienta administrativa para aprovisionar el objeto SecurityEventReceiverService con un nombre de usuario y una contraseña. Desproteger el archivo SecurityEventServiceAdministration.cs en la carpeta de complementario paso 3. Incluye las modificaciones necesarias a la extensión de comandos Stsadm.exe.

Las dependencias del servicio de Windows

En este punto, puede iniciar y detener instancias de servicio proporcionado en servidores de SharePoint y los servicios de conservan sus cuentas de seguridad. Sin embargo, si detiene ambas instancias de servicio y, a continuación, intentar iniciar la instancia SecurityEventHandlerService sin iniciar primero la instancia SecurityEventReceiverService en un servidor seleccionado, se encuentra un error que indica que "la dependencia de servicio o grupo error al iniciar." La causa es que el programa de configuración de auditoría de seguridad configura el servicio de controlador de eventos de seguridad dependen el servicio de receptor de eventos de seguridad de modo que el administrador de control de servicios (SCM) inicie el servicio de receptor de eventos de seguridad automáticamente cuando se inicia el servicio de controlador de eventos de seguridad. Sin embargo, el administrador de configuración de seguridad no puede iniciar un servicio si su tipo de inicio está deshabilitado, y SharePoint establece el tipo de inicio a deshabilitado cuando se detiene una instancia de servicio. Considere cambiar la lógica de instalador del servicio. Puede evitar este error si quita todas las dependencias e instalar que los servicios de inicialmente con el tipo de inicio se establece en deshabilitado. Esto garantiza un comportamiento de control coherente en Administración central de SharePoint 3.0.

Es excelente evitar errores desagradables resultantes, aunque existían las dependencias originales por una razón. Después de todo, el servicio de controlador de eventos de seguridad y servicio receptor de eventos de seguridad dependen entre sí para una solución funcional de auditoría de seguridad. Si iniciar o detener la, también deberá iniciar o detener el otro. Puede lograr este comportamiento, reemplazando los métodos de provisión y Desabastecimiento en las instancias de servicio. El SecurityEventReceiverServiceInstance intenta localizar su homólogo SecurityEventHandlerServiceInstance en el mismo servidor y inicia o detiene, junto con su propia instancia, si se encuentra. El código también muestra cómo personalizar los vínculos de acción iniciar y detener para mostrar un cuadro de mensaje en la interfaz de usuario para informar al administrador acerca de los servicios afectados.

Si analizar el código fuente en la carpeta de complementario del paso 4, observará que la clase SecurityEventHandlerServiceInstance no contiene métodos de provisión y Desabastecimiento reemplazados. Es suficiente iniciar y detener los servicios a través de la clase SecurityEventReceiverServiceInstance. En su lugar, marca el SecurityEventHandlerServiceInstance como un servicio del sistema, que quita el correspondiente iniciar y detener los vínculos y oculta el servicio de la lista de servicios configurables. La referencia SecurityEventHandlerService ahora es visible sólo en la vista todos los de los servicios en la página de servidor. El código siguiente muestra cómo marcar una instancia de servicio como un servicio del sistema:

public overrid  e bool SystemService
{
    get
    {
        return true;
    }
}

Agregar parámetros de configuración

La solución es ahora una parte integral de SharePoint. El siguiente paso es mover configuración relevantes desde el registro local a la base de datos de configuración de SharePoint para aumentar la coherencia de la configuración en el conjunto de servidores de SharePoint completo. Todas las instancias de servicios comparten la misma base de datos de configuración. Sólo tiene que modificar los servicios de Windows para leer los parámetros de la base de datos en lugar del registro de configuración. Para mantener los parámetros de la base de datos de configuración, utilice la clase SPPersistedObject, tal como se explica en el SDK de WSS 3.0 en" Clase SPPersistedObject (Microsoft.SharePoint.Administration)."

Las clases SPWindowsService y SPWindowsServiceInstance se derivan de la clase SPPersistedObject y, por tanto, son mis clases SecurityEventReceiverService y SecurityEventReceiverServiceInstance. Esto significa que puede agregar parámetros globales como propiedades almacenadas directamente a las clases de instancia de servicio y el servicio. En mi ejemplo, estos son los parámetros SiteURL, nombre de lista y EventFilter. La clase SecurityEventReceiverServiceInstance sería la elección correcta para los parámetros específicos de instancia, pero en Mi solución de todas las instancias de servicio se supone que para utilizar la misma configuración, por lo que extiende la clase SecurityEventReceiverService.

Para recuperar valores de parámetro, necesitará acceso a la base de datos de configuración. SharePoint se encarga de esto que si mantiene la identidad de proceso de su credencial de clase de servicio de implementación de habilitado (IsCredentialDeploymentEnabled = true). Hizo para la clase de servicio receptor de eventos de seguridad, pero el servicio de Windows también debe saber cómo utilizar la clase de servicio. Puede se encargan de este requisito mediante la adición de una clase - referencia de biblioteca para Visual Studio del proyecto que contiene el servicio de Windows. En mi ejemplo, esto es el proyecto SecurityEventReceiver. Asegúrese de que marca la clase SecurityEventReceiverService como pública para que el servicio de Windows pueda usarlo y implementar ensamblado de la biblioteca de clase en la caché de ensamblados global (GAC) por medio de su paquete de solución SharePoint. Tiene que implementar en la GAC antes de utilizar el método GetValue del conjunto de servicios del conjunto para recuperar el objeto de servicio. Del siguiente modo acceso a las propiedades configuración de la clase SecurityEventReceiverService:

SecurityEventReceiverService EventReceiverService =
    SPFarm.Local.Services.GetValue<SecurityEventReceiverService>(
        SecurityEventReceiverService.ntServiceName);

if (EventReceiverService == null)
    throw new Exception("Unable to locate SecurityEventReceiverService"
                      + " in the local SharePoint farm.");
siteURL = EventReceiverService.SiteURL;
listName = EventReceiverService.ListName;
eventFilter = EventReceiverService.EventFilter;

Ahora que el servicio de Windows puede leer los parámetros de la base de datos de configuración, la tarea pendiente es que establecerlos. La elección preferida para muchos administradores es una página de aplicación personalizada, agrega a la administración central de SharePoint 3.0 y ligado a un servicio a través de la propiedad ManageLink, pero también puede utilizar las extensiones de comandos de Stsadm.exe u otros métodos. El código siguiente utiliza la propiedad de ManageLink, agregada a la clase SecurityEventReceiverServiceInstance.

public override SPActionLink ManageLink
{
    get
    {
      return new 
        SPActionLink("SecurityAudit/ManageSecurityAuditSettings.aspx");
    }
}

Nombre para mostrar el servicio convierte en un hipervínculo que abre la página _admin/SecurityAudit/ManageSecurityAuditSettings.aspx. Encontrará la página ManageSecurityAuditSettings.aspx en una biblioteca de clase independiente, que denomina ManageSecurityAuditSettings. Para obtener más información sobre cómo crear páginas de aplicación personalizada, lea el artículo de Ted Pattison" Crear una página de aplicación en Windows SharePoint Services 3.0." Consulte también la carpeta de complementario paso 5.

Pruebas y toque final

El proyecto ya está casi terminado, aparte de retoques y probar la solución adecuada. Por ejemplo, es posible que desee cambiar el nombre para mostrar de los servicios de administración central de SharePoint 3.0 porque los nombres predeterminados SecurityEventManagement.SecurityEventHandlerService y SecurityEventManagement.SecurityEventReceiverService no son muy usuario descriptivo. Sin embargo, no conseguir el efecto deseado reemplazando la propiedad DisplayName en sus clases de servicio. El nombre de presentación corresponde a la propiedad TypeName en su lugar, por lo que nunca se basan en TypeName == GetType().ToString() en una solución de SharePoint.

Tenga en cuenta también que servicios y las clases de instancia de servicio ofrecen una propiedad TypeName porque se hereda de la clase SPPersistedObject, pero hay una relación quasi-hierarchical. Las instancias de servicio de utilizar el nombre de su servicio asociado, de forma predeterminada. Las clases de instancia de servicio heredan una propiedad TypeName reemplazada de la clase SPServiceInstance que devuelve el TypeName de la clase de servicio asociado. Por supuesto, puede reemplazar la propiedad TypeName en la clase de instancia del servicio nuevo para cambiar el nombre de presentación según determinadas condiciones, como para indicar que un componente fundamental es que faltan.

Terminología de SharePoint no es tan coherente como podría ser, pero no es difícil determinar el propósito de los métodos virtuales y las propiedades, independientemente de sus nombres. Para determinar las propiedades y métodos en Visual Studio, disponibles haga clic con el botón secundario en una clase base, como SPWindowsService y seleccione recibir en la definición y haga clic con el botón secundario SPService, tener A definición, y así sucesivamente mediante la jerarquía completa herencia. También puede comprobar el SDK de WSS 3.0. No se tratan las clases SPWindowsService y SPWindowsServiceInstance, pero las listas de miembros de clase son útiles para algunas (grado Los miembros de SPWindowsService y Los miembros de SPWindowsServiceInstance).

Sin embargo, recuerde que prueba correcta de servicio y las implementaciones de instancia de servicio en un equipo de desarrollo único no es un criterio de lanzamiento suficiente para servicios de Windows integrada de SharePoint. Administración central de SharePoint 3.0 ocupa servicios de Windows bastante diferente en el equipo local que en equipos remotos de un conjunto de servidores. Localmente, administración central de SharePoint 3.0 utiliza el contexto de seguridad del administrador de SharePoint ha iniciado la sesión, que es lo más probable es que un administrador local con todos los permisos necesarios para realizar acciones administrativas en los servicios. De forma remota, sin embargo, administración central de SharePoint 3.0 utiliza trabajos del temporizador y el servicio SPTimerV3. Como mencioné anteriormente, seguridad cuenta el servicio SPTimerV3 no es un administrador local en el equipo remoto, para el servicio SPTimerV3 utiliza el servicio SPAdmin para llevar a cabo las acciones en el contexto de la cuenta Sistema local. Para asegurarse de que las diferencias en contextos de seguridad no interfieran con el estado operativo de los servicios de Windows, recomendamos que pruebe completamente la solución en un entorno de conjunto de servidores con al menos dos servidores front-end y un equipo independiente que ejecuta SQL Server en una configuración de seguridad restrictiva según a la " Los requisitos de cuenta de seguridad de Windows SharePoint Services"hoja de cálculo.

Sumar hacia arriba

Debe prestar atención especial a diseño de la solución y la seguridad cuando va a crear servicios de Windows integrada de SharePoint, pero dado el trabajo adecuado, la integración con SharePoint real es relativamente uncomplicated. El modelo de objetos de SharePoint ya incluye la lógica necesaria para aprovisionar, iniciar, detener y desprovea instancias de servicio en servidores locales y remotos un conjunto de servidores de SharePoint. Sólo es necesario definir servicio correspondiente y clases de instancia de servicio para integrar los servicios de Windows en la configuración de SharePoint. Instancia de servicio y servicio las clases derivadas de la clase SPPersistedObject, lo que significa que puede utilizar estas clases para mantener los parámetros de servicios directamente de la base de datos de configuración de SharePoint en lugar del registro local, lo que mejora la coherencia de facilidad de administración y configuración.

En general, una solución completa que aparece perfectamente integrada con SharePoint debe incluir las herramientas administrativas de Servicios de Windows para objetos provisión del servicio, páginas de aplicación para ampliar Administración central de SharePoint 3.0 y un paquete de solución de SharePoint para implementar los componentes de SharePoint en todos los servidores del conjunto junto con los servicios de Windows reales. Servicios de Windows son los componentes esenciales de servidores de Windows, y con las capacidades de integración disponibles en SharePoint pueden asumir funciones críticas en el entorno de SharePoint así. Para obtener más información, consulte www.microsoft.com/SharePoint, msdn2.microsoft.com/SharePoint, Documentación de SDK de Windows SharePoint Services, y blogs.msdn.com/SharePoint.

Pav Cherny es un experto en TI y el autor especializado en tecnologías de Microsoft para la colaboración y comunicación unificada. Sus publicaciones incluyen notas del producto, manuales de producto y libros con un foco sobre las operaciones y administración del sistema. Pav es presidente de Biblioso Corporation, una empresa que está especializada en servicios administrados de documentación y localización.