Este artigo foi traduzido por máquina.

Assumir controle

Usar o SharePoint para gerenciar seus serviços do Windows

Pav Cherny

Download do código disponível na Galeria de código do MSDN
Procure o código on-line

Conteúdo

Um protótipo de solução não-integrado ao
Integração com o SharePoint
Definição de identidades do processo
Dependências de serviços do Windows
Adicionar parâmetros de configuração
Toques finais e testando
Soma para cima

Todos os sistemas de operacionais Windows Server dependem muito serviços do Windows. Isso não alterados desde que Microsoft introduzidos serviços com o Microsoft Windows NT 3.1 em 1993 e provavelmente não será alterado no futuro sistemas operacionais ou. Até mesmo SharePoint não foi possível existir sem serviços do Windows, tais como serviços de informações da Internet (IIS) e outros serviços para tarefas específicas do SharePoint. Você pode aproveitar a infra-estrutura serviços internos por meio de trabalhos personalizados para o serviço Windows SharePoint Services Timer (SPTimerV3), mas se você deseja processamento de dados abrangente, monitoramento do sistema contínuo, verificação de vírus, rede de comunicação ou baseado em agente backup e restaurar as operações, é ainda melhor criar seus próprios serviços separados do Windows. Ele não é difícil criar um serviço do Windows. Microsoft Visual Studio 2008 inclui os modelos de projeto necessário e assistentes para obter começar e você podem usar c/c++ bem como idiomas gerenciados para implementar a lógica de serviço. No entanto, não é tão simples integrar um serviço do Windows SharePoint. O Windows SharePoint Services (WSS) 3.0 Software Development Kit (SDK) não aborda esse tópico muito bem, existem não assistentes e você deve garantir que os resultados de integração por em não risco segurança do SharePoint.

Neste artigo, mostrarei como integrar uma solução de services–based do Windows SharePoint. Os resultados permitem que você configurar, iniciar, parar e remover instâncias do serviço por meio de Administração Central do SharePoint 3.0 e o modelo de objeto de administração do SharePoint, manter configurações de serviço centralmente no banco de dados de configuração do SharePoint e garantir que todas as instâncias do serviço em um farm do SharePoint usem os mesmos parâmetros de conta e a configuração de segurança. Quando você altera as configurações do SharePoint, você pode aplicar as alterações consistente em todos os servidores no farm. Obviamente, também é possível configurar parâmetros separadamente para instâncias de serviço individuais, se necessário. Para minha solução de exemplo, eu optei por executar uma operação confidencial em servidores front-end para realçar as considerações de segurança específico do SharePoint. O material complementar inclui código-fonte e compilados arquivos em vários estágios de conclusão de acordo com a seqüência de etapas que discutirei aqui. O material complementar também inclui planilhas passo a passo sobre se você deseja seguir Minhas explicações no seu próprio ambiente de desenvolvimento.

Um protótipo de solução não-integrado ao

É uma prática melhor para iniciar um ciclo de desenvolvimento por reunir os requisitos, tópicos de um projeto da solução geral e fornecer prova de conceito na forma de um protótipo de representante. Isso é especialmente verdadeiro para serviços de SharePoint sensíveis à segurança que necessitam de permissões elevadas em servidores front-end ou servidores de aplicativos. Embora não seja necessário para integrar o protótipo SharePoint para gerenciamento, o protótipo deve abordar as dependências de segurança do SharePoint direita desde o início para evitar problemas de design complexos mais tarde. Mesmo aparentemente soluções simples podem representar desafios difícil em um ambiente do SharePoint.

Levar a solução de exemplo deste artigo, por exemplo. Ele aborda a necessidade de consolidar as entradas do Security log de eventos de servidores front-end em uma lista do SharePoint personalizada. É uma tarefa aparentemente simples: A solução registra um manipulador chamado EntryWrittenEventHandler no subsistema de log de eventos no computador local para receber uma notificação de evento sempre que o sistema operacional adiciona uma nova entrada no log de eventos de segurança e, em seguida, se a entrada de atender a um critério de filtro especificado, como tipo de entrada é igual a FailureAudit ou SuccessAudit, a solução adiciona um item correspondente a uma lista personalizada de auditoria de segurança no SharePoint. Ele não é difícil criar um serviço básico do Windows e uma lista do SharePoint personalizada para fazer isso, mas a conta de serviço requer permissões de gravação no site do SharePoint para adicionar itens à lista personalizada e permissões administrativas no servidor local para registrar EntryWrittenEventHandler — e esse é um problema de segurança em servidores do SharePoint.

Enquanto você pode atender aos requisitos de permissão a SharePoint executando o serviço do Windows no contexto da conta de pool de aplicativo do site do SharePoint, você não deve conceder permissões administrativas locais para contas de segurança do SharePoint. Conceder permissões administrativas nos servidores front-end de contas de segurança compromete a segurança do SharePoint, conforme explicado na coluna Janeiro de 2009 TechNet Magazine intitulada"Contas de segurança do SharePoint."

Portanto, como você evitar a elevação de permissões se sua solução deve executar uma operação sensível à segurança? Uma boa técnica é dividir a solução em vários componentes e use um mecanismo seguro de comunicação entre processos entre eles. Em seguida, você pode executar o componente que requer permissões administrativas no contexto da conta do sistema local, enquanto o outro componente é executado no contexto da conta de segurança do SharePoint. A Microsoft usa essa técnica no serviço SPTimerV3. SPTimerV3 é executado sem permissões administrativas no contexto da conta do farm do SharePoint e depende do serviço de administração do Windows SharePoint Services (SPAdmin) para executar tarefas administrativas no servidor local. O serviço SPAdmin é executado no contexto da conta sistema local. SPTimerV3 e SPAdmin usam .NET Remoting para comunicação entre processos, mas também é possível usar um mecanismo de peso mais claro, como pipes nomeados, desde que você protege o recurso de comunicação por meio de listas de controle de acesso (ACLs). A solução de exemplo, usarei a abordagem de pipe nomeado.

Dê uma olhada a arquitetura da solução geral na Figura 1 . A solução depende de um serviço separado do manipulador de eventos de segurança que inclui a função de retorno de chamada EntryWrittenEventHandler mencionados anteriormente para receber notificações do subsistema do log de eventos local. Esse serviço é executado no contexto da conta sistema local. Sua contraparte é o serviço receptor de eventos de segurança, que é executado no contexto da conta de pool de aplicativo do site do SharePoint para criar itens de conteúdo em uma lista de auditoria de segurança especificados. Quando você inicia o receptor de eventos de segurança, o serviço cria um pipe nomeado seguro que concede somente o local System conta acesso. O serviço de manipulador de eventos de segurança usa este pipe nomeado sempre que um evento "entrada do log de eventos segurança gravados" é acionado para se comunicar com o receptor de eventos de segurança. Esse design funciona sem a necessidade de permissões elevadas e sem jeopardizing segurança do SharePoint. É apenas um pouco mais atrativo que a arquitetura de serviço Windows monolítico típica.

Figura 1 dividindo até uma solução do SharePoint

Você pode observar no aplicativo de exemplo que o Microsoft .NET Framework não é possível analisar a descrição de entradas de segurança. Isso não é essencial para os fins deste artigo, mas, considere instalar o hotfix descrito no artigo da Base de Dados de Conhecimento da Microsoft"Um aplicativo que usa o log de eventos de segurança Windows NT APIs não é possível ler a descrição de uma mensagem no log de evento de um computador que está executando o Windows Vista ou Windows Server 2008."

Integração com o SharePoint

A entrega de um protótipo funcional é uma etapa importante; a outra é fornecer ferramentas de gerenciamento apropriadas e isso é um aspecto chave de integração do SharePoint para serviços do Windows. Sem integração, é difícil controlar instâncias do serviço implantado ou garantir um comportamento de serviço consistente em todos os servidores em um farm. Com a integração, você pode usar a Administração Central do SharePoint 3.0 para determinar os servidores que executar seus serviços e configurar os parâmetros relevantes para todas as instâncias de serviço centralmente. a Figura 2 mostra o aplicativo após concluir todas as etapas de integração. Ele pode parecer um pequeno aplicativo, mas integração do SharePoint concede a ele todas as características de uma solução do SharePoint completo.

A Figura 2 integração com o SharePoint

Basicamente, você precisa quatro componentes para integrar um serviço do Windows SharePoint: instâncias de uma classe que identifica o serviço, uma classe que permite que o SharePoint controlar o serviço individual, uma ferramenta administrativa que adiciona os objetos dessas duas classes para a configuração do SharePoint e um pacote de solução do SharePoint para implantar esses componentes.

Acordo com a arquitetura da solução aparece ilustrada na Figura 1 , há dois serviços do Windows: manipulador de eventos de segurança e o receptor de eventos de segurança. Portanto, vamos criar as classes de serviço correspondente em um novo projeto de biblioteca de classe. EU adicionar esse projeto diretamente à solução SecurityAudit que criei no Visual Studio. Ela é chamada SecurityEventManagement. Depois que eu adicionado uma referência à biblioteca do Windows SharePoint Services, criei uma nova classe derivada da classe SPWindowsService para cada serviço do Windows. Na implementação da classe SecurityEventReceiverService inicial, a classe SecurityEventHandlerService tem a mesma estrutura; apenas o nome do serviço é diferente, como você verá se você analisar o código na pasta etapa 2 do material complementar.

A classe de serviço representa um determinado serviço do Windows em um farm do SharePoint. É um objeto global para todas as instâncias de serviço, mas você também precisa uma classe para associar uma instância do serviço com um servidor específico do SharePoint. O modelo de objeto de administração do SharePoint define várias classes de base do serviço e as classes de instância de serviço ao qual eles correspondem. A classe de SPWindowsService é a escolha certa para os serviços do Windows, e, portanto, a classe SPWindowsServiceInstance é a classe direita base para as classes de instância do serviço: SecurityEventReceiverServiceInstance e SecurityEventHandlerServiceInstance. Novamente, as definições de classe são relativamente uncomplicated.

Agora mostrarei como construir a ferramenta administrativa para adicionar as serviço e objetos de instância de serviço para a configuração do SharePoint. Você pode fazer isso pelas páginas do aplicativo de Administração Central do SharePoint 3.0, as extensões de comando Stsadm.exe, ou por qualquer outro meio, como por meio do uso de Windows PowerShell. Optou por criar uma extensão de comando Stsadm.exe devido a seu baixa sobrecarga, que significa distração pouco do trabalho à mão. Para obter informações detalhadas sobre as extensões de comando Stsadm.exe, leia o artigo"Como: Estender o utilitário STSADM."

A ferramenta administrativa deve instanciar e manter o serviço e objetos de instância do serviço. Os construtores das classes revelam a instanciar os objetos. É que vale a pena observar que classes de serviço do SharePoint são derivados da classe SPPersistedObject. Quando você chamar o método Update(), esses objetos são mantidos. Da mesma forma, se você chamar o método de Delete() após cancelamento, esses objetos serão removidos novamente. O arquivo de código SecurityEventServiceAdministration.cs no projeto SecurityEventManagement ilustra essas etapas.

E isso é tudo! Agora você pode compilar a solução e implantá-lo através do uso de um pacote de solução do WSS 3.0 (.wsp). Para obter uma explicação detalhada de como criar um pacote de solução com o Visual Studio e MakeCab.exe, eu recomendoArtigo do Andrew Connellsobre como criar arquivos de solução do WSS. Também verá o código no material complementar.

Definição de identidades do processo

A simplicidade de integração do SharePoint pode ser uma surpresa interessante, mas é um resultado direto de ter obtido proveito total do modelo de objeto SharePoint. Você já pode configurar instâncias do serviço e usar os links de gerenciamento na Administração Central do SharePoint 3.0 (veja a Figura 3 ). Por exemplo, você pode iniciar e parar o serviço receptor de eventos de segurança; apenas o serviço do manipulador de eventos de segurança não é tão fácil. Isso acontece porque o SharePoint atualiza a configuração de serviço quando você clica no link início. Por padrão, o SharePoint configura o serviço para ser executado no contexto da conta de serviço local, que não tem permissões para registrar um EntryWrittenEventHandler. Portanto, o serviço de manipulador de eventos de segurança não. Você precisa hardwire o serviço de manipulador de eventos de segurança para a conta sistema local e deve fornecer uma opção para configurar o serviço receptor de eventos de segurança com uma conta de pool aplicativo desejado bem.

A Figura 3 Administração Central do SharePoint 3.0

Vamos começar com o serviço de manipulador de eventos de segurança porque ele é simples de hardwire a conta do sistema. Bastam três linhas de código no construtor de serviço. A primeira linha define a identidade do processo do serviço para a conta do sistema. As outras duas linhas desabilite implantações de credencial e credencial atualizações para impedir que os administradores façam alterações as informações da conta na Administração Central do SharePoint 3.0. A página de contas de serviço (_admin/FarmCredentialManagement.aspx) não lista este serviço na caixa de listagem de serviço do Windows.

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

O serviço receptor de eventos de segurança é um pouco mais complicado porque você deve manipular uma variedade de segurança informações de conta durante a configuração do serviço. A conta de segurança pode ser uma conta de usuário de domínio com uma senha ou uma conta do sistema sem uma senha. Quando você lida com uma conta de usuário de domínio, o nome da conta deve seguir as convenções de nome NetBIOS e você deve verificar a senha. Em minha implementação, o código define as propriedades IsCredentialDeploymentEnabled e IsCredentialUpdateEnabled dessa classe como true para que os administradores do SharePoint podem alterar a conta de segurança na Administração Central do SharePoint 3.0 após o serviço receptor de eventos de segurança de configuração.

Obviamente, você também deve estender a ferramenta administrativa para configurar o objeto SecurityEventReceiverService com um nome de usuário e senha. Check-out o arquivo SecurityEventServiceAdministration.cs na pasta complementar etapa 3. Ele inclui as modificações necessárias para a extensão de comando Stsadm.exe.

Dependências de serviços do Windows

Neste ponto, você pode iniciar e interromper instâncias do serviço configurado em servidores do SharePoint e os serviços de mantêm suas contas de segurança. No entanto, se você interromper as duas instâncias do serviço e tente iniciar a instância SecurityEventHandlerService sem primeiro iniciar a instância SecurityEventReceiverService em um servidor selecionado, você encontrar um erro informando que "o serviço de dependência ou grupo falha ao iniciar." A causa é que o programa de segurança auditoria instalação configura o serviço de manipulador de eventos de segurança para dependem do serviço receptor de eventos de segurança para que seja o Gerenciador de controle de serviço (SCM) iniciado o serviço receptor de eventos de segurança automaticamente quando você inicia o serviço de manipulador de eventos de segurança. No entanto, o SCM não é possível iniciar um serviço se o tipo de inicialização estiver desativado, e o SharePoint define o tipo de inicialização como desativado quando você parar uma instância do serviço. Considere alterar a lógica de instalador de serviço. Você pode evitar esse erro se você remover todas as dependências e instalar que os serviços inicialmente com o tipo de inicialização definidos como desabilitado. Isso garante um comportamento consistente de controle na Administração Central do SharePoint 3.0.

Ele é ótimo evitar erros desagradável, mas as dependências originais existiam por um motivo. Afinal de contas, serviço de manipulador de eventos de segurança e serviço receptor de eventos de segurança dependem uns aos outros para uma funcionamento solução de auditoria de segurança. Se você inicia ou parar o, você deve também iniciar ou interromper o outro. Você pode obter esse comportamento, substituindo os métodos de criar e desconfiguração nas instâncias de serviço. O SecurityEventReceiverServiceInstance tenta localizar sua contraparte SecurityEventHandlerServiceInstance no mesmo servidor e inicia ou pára-juntamente com sua própria instância, se localizado. O código também demonstra como personalizar os links de ação de início e parada para exibir uma caixa de mensagem na interface do usuário para informar o administrador sobre os serviços afetados.

Se você analisar o código-fonte na pasta de complementar a etapa 4, você irá notar que a classe SecurityEventHandlerServiceInstance não contém métodos de criar e desconfiguração substituídos. É suficiente iniciar e interromper os serviços através da classe SecurityEventReceiverServiceInstance. Em vez disso, eu marcada a SecurityEventHandlerServiceInstance como um serviço de sistema, que remove o menu correspondente e Stop links e oculta o serviço de lista de serviços configuráveis. A referência SecurityEventHandlerService agora é visível somente no modo de todos os exibição dos serviços na página do servidor. O código a seguir mostra como marcar uma instância do serviço como um serviço de sistema:

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

Adicionar parâmetros de configuração

A solução agora é parte integral do SharePoint. A próxima etapa é mover as configurações relevantes de Registro local para o banco de dados de configuração do SharePoint para aumentar a configuração consistência entre o farm do SharePoint inteiro. Todas as instâncias do serviço compartilham o mesmo banco de dados de configuração. Você só precisará modificar os serviços do Windows para ler os parâmetros de banco de dados de configuração em vez do registro. Para manter parâmetros no banco de dados de configuração, use a classe SPPersistedObject, conforme explicado no WSS 3.0 SDK em" Classe SPPersistedObject (Microsoft.SharePoint.Administration)."

As classes SPWindowsService e SPWindowsServiceInstance são derivadas da classe SPPersistedObject e, portanto, são minhas classes SecurityEventReceiverService e SecurityEventReceiverServiceInstance. Isso significa que você pode adicionar parâmetros globais como propriedades persistentes diretamente para o serviço e classes de instância de serviço. No meu exemplo, esses são os parâmetros SiteURL, ListName e EventFilter. A classe SecurityEventReceiverServiceInstance deve ser a escolha certa para parâmetros específicos de instância, mas na minha solução todas as instâncias de serviço devem para usar as mesmas configurações, para que eu estendido a classe SecurityEventReceiverService.

Para recuperar valores de parâmetro, você precisa acessar o banco de dados de configuração. SharePoint se encarrega de isso para você se você mantiver a identidade do processo do serviço classe credencial implantação habilitado (IsCredentialDeploymentEnabled = true). Fiz isso para a classe de serviço receptor de eventos de segurança, mas o serviço do Windows também deve saber como usar a classe de serviço. Você pode observar desse requisito adicionando uma referência de biblioteca de classe ao projeto do Visual Studio que contém seu serviço do Windows. No meu exemplo, este é o projeto de SecurityEventReceiver. Verifique se que você marca a classe de SecurityEventReceiverService como pública para que o serviço do Windows possa usá-lo e implantar assembly a biblioteca de classes no global assembly cache (GAC) por meio de seu pacote de solução do SharePoint. Você precisará implantar o GAC antes de usar o método GetValue da coleção de serviços do farm para recuperar o objeto de serviço. Veja como acessar as propriedades de configuração da classe 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;

Agora que o serviço do Windows pode ler os parâmetros do banco de dados de configuração, a tarefa restante é configurá-los. A opção preferencial para muitos administradores é uma página de aplicativo personalizado, adicionado à Administração Central do SharePoint 3.0 e vinculado ao serviço usando a propriedade ManageLink, mas você também pode usar as extensões de comando Stsadm.exe ou outros métodos. O código a seguir usa a propriedade de ManageLink, adicionada à classe SecurityEventReceiverServiceInstance.

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

Converte o nome do serviço exibição em um hiperlink que abre a página _admin/SecurityAudit/ManageSecurityAuditSettings.aspx. Você pode encontrar a página ManageSecurityAuditSettings.aspx em uma biblioteca de classe separada, chamei ManageSecurityAuditSettings. Para obter detalhes sobre como criar páginas de aplicativos personalizados, ler o artigo de Ted Pattison" Criando uma página de aplicativo no Windows SharePoint Services 3.0." Consulte também a pasta de complementar etapa 5.

Toques finais e testando

O projeto agora está quase concluído, além de toques e teste da solução apropriada. Por exemplo, talvez queira alterar o nome de exibição de seus serviços na Administração Central do SharePoint 3.0 porque os nomes padrão SecurityEventManagement.SecurityEventHandlerService e SecurityEventManagement.SecurityEventReceiverService não são muito amigável. Entretanto, você não obter o efeito desejado, substituindo a propriedade DisplayName de suas classes serviço. O nome de exibição corresponde à propriedade TypeName em vez disso, portanto, nunca dependem TypeName == GetType().ToString() em uma solução do SharePoint.

Observe também que serviço e classes de instância de serviço oferecem uma propriedade TypeName porque ela é herdada da classe SPPersistedObject, mas há uma relação quasi-hierarchical. Instâncias do serviço usam o nome do seu serviço associado, por padrão. Classes de instância de serviço herdar uma propriedade TypeName substituída da classe SPServiceInstance que retorna o TypeName da classe de serviço associado. Obviamente, você pode substituir a propriedade TypeName na sua classe instância de serviço novamente para alterar o nome para exibição acordo com a determinadas condições, como para indicar que um componente essencial está faltando.

Terminologia do SharePoint não é consistente pode ser, mas não é difícil determinar a finalidade dos métodos virtuais e propriedades, independentemente de seus nomes. Para determinar propriedades disponíveis e métodos, no Visual Studio, clique com o botão direito do mouse em uma classe base, como SPWindowsService e selecione tem para definição e clique com o botão direito SPService, tem A definição, e assim por diante por meio a hierarquia de herança inteiro. Você também pode verificar o SDK do WSS 3.0. As classes SPWindowsService e SPWindowsServiceInstance raramente são abordadas, mas as listas de membros de classe são úteis para alguns (grau SPWindowsService membros e SPWindowsServiceInstance membros).

Tenha em mente, porém, esse teste bem-sucedida de serviço e implementações de instância de serviço em um computador de desenvolvimento único não é um critério de versão suficientes para serviços do SharePoint-integrada ao Windows. Administração Central do SharePoint 3.0 lida com os serviços do Windows é diferente no computador local que em computadores remotos em um farm. Localmente, a Administração Central do SharePoint 3.0 usa o contexto de segurança do administrador do SharePoint com logon feito, que é mais provável que um administrador local com todas as permissões necessárias para executar ações administrativas em serviços. Remotamente, no entanto, Administração Central do SharePoint 3.0 usa trabalhos de timer e o serviço SPTimerV3. Como mencionado anteriormente, o conta de segurança do serviço SPTimerV3 não é um administrador local no computador remoto, portanto, o serviço de SPTimerV3 usa o serviço SPAdmin para executar as ações no contexto da conta sistema local. Para garantir que as diferenças nos contextos de segurança não interferem com o estado operacional dos seus serviços do Windows, eu recomendo que você teste totalmente sua solução em um ambiente de farm com pelo menos dois servidores front-end e um computador separado executando o SQL Server em uma configuração segurança restritivas acordo com o " Requisitos de conta de segurança do Windows SharePoint Services"planilha.

Soma para cima

Você precisará prestar atenção especial à segurança e de projeto da solução quando você está criando serviços do Windows integrada ao SharePoint, mas devido a base adequada, a integração real com o SharePoint é relativamente uncomplicated. O modelo de objeto SharePoint já inclui a lógica necessária para configurar, iniciar, parar e desconfigurar instâncias de serviço em servidores locais e remotos em um farm do SharePoint. Você só precisa definir serviço correspondente e classes de instância de serviço para integrar os serviços do Windows a configuração do SharePoint. Instância de serviço e de serviço classes são derivados da classe SPPersistedObject, que significa que você pode usar essas classes para manter os parâmetros de serviço diretamente no banco de dados de configuração SharePoint, em vez do Registro local, resultando em aprimorado consistência de gerenciamento e configuração.

Em geral, uma solução de recursos completos que aparece perfeitamente integrada ao SharePoint deve incluir as ferramentas administrativas do Windows serviços a provisão objetos de serviço, páginas de aplicativo para estender a funcionalidade Administração Central do SharePoint 3.0 e um pacote de solução do SharePoint para implantar os componentes do SharePoint em todos os servidores do farm com os serviços do Windows reais. Serviços do Windows são componentes essenciais nos servidores Windows e com os recursos de integração disponíveis no SharePoint podem assumir funções importantes no ambiente do SharePoint. Para obter mais informações, consulte www.microsoft.com/SharePoint, msdn2.microsoft.com/SharePoint, Documentação de SDK do Windows SharePoint Services, e blogs.msdn.com/SharePoint.

pav Cherny é um especialista IT e autor especializado em tecnologias Microsoft para colaboração e a comunicação unificada. Suas publicações incluem informes oficiais, manuais de produto e livros com um foco em operações de TI e administração do sistema. Pav é presidente da Biblioso Corporation, uma empresa especializada em serviços de documentação e localização gerenciados.