Explorando o SharePointCriando a infra-estrutura do SharePoint

Pav Cherny

Faça download do código deste artigo: SharePoint2008_05.exe (412KB)

Da mesma forma que o sistema de mensagens por email transformou a comunicação comercial, a colaboração baseada na Web está mudando a maneira como as pessoas trabalham juntas e compartilham informações. Como um bom exemplo disso, observe o que a tecnologia do SharePoint oferece. Com o WSS (Microsoft Windows SharePoint Services) 3.0 e o MOSS

(Microsoft Office SharePoint Server) 2007, é possível criar sites de equipe, portais, soluções em gerenciamento de conteúdo da Web, bibliotecas de documentos e centros de pesquisa, isso sem mencionar a integração do 2007 Microsoft® Office system, os formulários baseados em XML, os fluxos de trabalho, o suporte à mobilidade etc.

No entanto, a introdução ao SharePoint® nem sempre é simples. A terminologia pode ser confusa. A arquitetura do sistema pode ser complexa, e o SharePoint exige que você lide com vários componentes, dentre os quais estão o IIS, o Microsoft .NET Framework, o SQL Server® e possivelmente outras tecnologias como, por exemplo, Business Intelligence, InfoPath® Forms Services, RMS (Rights Management Services), Exchange Server e ForefrontTM Security.

É possível se perder rapidamente em meio a integrações e personalizações, dadas as muitas abordagens possíveis para criar soluções em SharePoint, independentemente de ser por meio da interface do usuário interna ou programaticamente. Além disso, quando um aplicativo do SharePoint não funciona, a solução de problemas pode ser complicada. Muitas vezes, você deve ter a cabeça de um desenvolvedor de aplicativo para compreender os componentes envolvidos e a forma como eles interagem. Com todos esses desafios, por onde você começa a criar uma infra-estrutura do SharePoint eficiente, escalonável e gerenciável?

Nesta coluna, mostrarei como começar inicialmente estabelecendo as bases com uma discussão sobre a arquitetura em alto nível e, em seguida, mergulhando na implantação do WSS, incluindo personalizações extremamente básicas da identidade visual. Usando o recurso Self-Service Site Management do WSS 3.0, você verá como delegar permissões para criar e gerenciar sites do SharePoint a usuários individuais ao mesmo tempo em que mantém o controle administrativo centralizado sobre a infra-estrutura do SharePoint.

Observando primeiramente a arquitetura do SharePoint, fica mais fácil compreender as etapas da implantação e da configuração necessárias à implementação de uma infra-estrutura flexível e escalonável. Portanto, vejamos rapidamente as dependências e, em seguida, passamos diretamente à implantação do WSS 3.0. Para obter instruções detalhadas quanto à implantação, consulte o material complementar para referência. É possível encontrar esse material na seção de downloads do site da TechNet Magazine em technetmagazine.com.

Arquitetura do SharePoint

Com o SharePoint, é importante pensar na tecnologia do ponto de vista de um arquiteto de sistema. Você não precisa saber todos os mínimos detalhes, mas caso esteja familiarizado com as dependências gerais que surgem da arquitetura do SharePoint, você pode chegar mais rapidamente a soluções porque é possível prever o necessário à configuração e o porquê.

O SharePoint é uma tecnologia destinada a provisionar aplicativos Web e sites. Trata-se de uma solução em site baseada no IIS que se integra ao IIS por meio do ASP.NET e que conta com um back-end do banco de dados do SQL Server para armazenar dados e conteúdo da configuração. Em suma, o SharePoint combina três arquiteturas diferentes em seu núcleo (IIS, .NET e SQL Server), como ilustrado na Figura 1.

Figure 1** WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0 **(Clique na imagem para aumentar a exibição)

Não deixe que o diagrama o intimide. A arquitetura pode parecer exagerada inicialmente, considerando o número impressionante de componentes. Mas todos eles se encaixam em uma estrutura lógica que, quando examinada sistematicamente, esclarece as dependências do componente.

Conforme a representação, o SharePoint depende do IIS e do ASP.NET para lidar com solicitações e respostas HTTP. Componentes padrão do IIS como, por exemplo, o driver de modo kernel HTTP (http.sys) e o Processo de Trabalho (w3wp.exe), realizam o enfileiramento inicial e o roteamento das solicitações até que elas cheguem ao filtro ISAPI do ASP.NET (aspnet_isapi.dll). Quando você instala o .NET Framework, a rotina de instalação registra aspnet_isapi.dll na metabase do IIS (C:\Windows\System32\Inetsrv\metabase.xml) da seguinte forma:

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"

Assim que o IIS carrega o filtro ISAPI do ASP.NET, todas as solicitações de entrada referentes a um site podem ser passadas para o ASP.NET, o que é importante porque o SharePoint deve acabar recebendo essas solicitações por meio do ASP.NET. Para conseguir isso, o SharePoint estende a configuração do site selecionado adicionando um mapa de aplicativo curinga que roteia todas as solicitações de entrada, independentemente da extensão do nome do arquivo, para o filtro ISAPI do ASP.NET.

É possível ver isso no Gerenciador do IIS depois da instalação do WSS 3.0 usando a opção de instalação Básica. A rotina de instalação do WSS desativa o site do IIS padrão existente no servidor e cria um novo site padrão na porta 80 em que o mapa de aplicativo curinga do ASP.NET está definido, como mostrado na Figura 2.

Figure 2** Wildcard application map for ASP.NET ISAPI filter **(Clique na imagem para aumentar a exibição)

Para que o ASP.NET, por sua vez, passe as solicitações para o SharePoint, este também deve estender o Pipeline de Solicitação HTTP em meio a um objeto HttpApplication personalizado, implementado por meio de uma classe chamada SPHttpApplication no assembly do Microsoft.SharePoint. O SharePoint define esse objeto de aplicativo personalizado no arquivo de aplicativo do ASP.NET (global.asax), que é possível encontrar no sistema de arquivos, na pasta raiz dos sites do SharePoint estendido. O seguinte código lista o conteúdo desse arquivo global.asax:

<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>

O ASP.NET analisa dinamicamente e compila esse arquivo para instanciar o objeto de aplicativo do SharePoint.

Para cada solicitação recebida, o ASP.NET dispara uma série de eventos que o aplicativo Web pode processar como, por exemplo, BeginRequest, AuthenticateRequest, ProcessRequest e EndRequest. Os detalhes da manipulação de eventos estão além do escopo da implantação e do gerenciamento do SharePoint, embora seja importante saber que, além de SPHttpApplication especificado em global.asax, o SharePoint implementa identificadores HTTP personalizados e módulos definidos no arquivo web.config do site. Por exemplo, o SharePoint usa um módulo HTTP baseado na classe SPRequestModule, registrado como sendo o primeiro módulo HTTP antes dos módulos padrão do ASP.NET. SPRequestModule inicializa o ambiente de runtime do SharePoint como, por exemplo, registrando um componente SPVirtualPathProvider com o ASP.NET. SPRequestModule se destina ao uso interno do SharePoint, mas os desenvolvedores de solução em SharePoint podem modificar o arquivo web.config para registrar componentes adicionais como, por exemplo, manipuladores e módulos HTTP. Por meio de módulos HTTP personalizados e padrão, o SharePoint usufrui o ASP.NET ao mesmo tempo em que mantém um controle rígido sobre todas as solicitações para aplicativos do SharePoint.

Observe que, quando você cria um aplicativo Web usando o site de Administração Central do SharePoint 3.0, o WSS adiciona o mapa de aplicativo curinga do ASP.NET ao site do IIS selecionado e cria os arquivos global.asax e web.config na pasta raiz do site. Cada aplicativo Web usa seu próprio conjunto de arquivos global.asax e web.config de nível superior.

Para processar solicitações e retornar informações significativas para os navegadores, o WSS 3.0 e o MOSS 2007 contam com o analisador de páginas padrão do ASP.NET, que compila as páginas do ASP.NET solicitadas ou as processa no modo de não-compilação. Mas as páginas do ASP.NET que o SharePoint passa para o analisador do ASP.NET não estão necessariamente localizadas onde aparentam existir. Por exemplo, você não poderá encontrar um arquivo default.aspx na pasta raiz de um site do SharePoint estendido como, por exemplo, o site de Administração Central do SharePoint 3.0, ainda que esteja abrindo default.aspx ao exibir a home page do site. É o componente SPVirtualPathProvider que virtualiza o ambiente carregando o conteúdo da página no sistema de arquivos local ou em um banco de dados de conteúdo do SQL Server e passando-o como um arquivo virtual para o analisador de páginas do ASP.NET. Para o site de Administração Central, o SharePoint carrega o arquivo default.aspx na pasta C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin.

A home page, bem como a maior parte das demais páginas do site do SharePoint, está vinculada a uma página mestra do ASP.NET (default.master) que implementa um mesmo layout para menus e controles de navegação. Default.master reside na pasta C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global e inclui espaços reservados nomeados para mais páginas de conteúdo que também podem residir no sistema de arquivos local ou em um banco de dados de conteúdo do SQL Server. O ponto-chave é que, ao abrir um site do SharePoint em um navegador da Web, você está, na verdade, exibindo informações de uma coleção de páginas de conteúdo que não estão necessariamente localizadas no servidor Web local e que estão organizadas de acordo com um layout definido em uma página mestra.

A regra geral é que as páginas não-modificadas (ou não-personalizadas, na terminologia do SharePoint) existem como modelos de página no sistema de arquivos local de todos os servidores do SharePoint e que as páginas personalizadas são gravadas no banco de dados de conteúdo para que todos os servidores do SharePoint em um web farm tenham acesso ao mesmo conjunto de páginas (consulte a Figura 3). Pressupõe-se que as páginas não-personalizadas sejam idênticas em todos os servidores e sites do web farm. No entanto, caso você personalize uma página de conteúdo ou uma página mestra em um site do SharePoint, talvez usando o Office SharePoint Designer 2007, o SharePoint armazena automaticamente a página personalizada no banco de dados do conteúdo.

Figure 3** Uncustomized and customized ASP.NET pages in a SharePoint application **(Clique na imagem para aumentar a exibição)

Além de páginas personalizadas e outros conteúdos do site, o SharePoint também armazena dados de configuração em um banco de dados do SQL Server. O SharePoint mantém os dados de configuração separados do conteúdo porque eles são globais por natureza e o conteúdo, específico de cada aplicativo Web individual e conjunto de sites. Dessa forma, um web farm só pode ter um único banco de dados de configuração, embora possa ter vários bancos de dados de conteúdo.

Todos os servidores do WSS no web farm usam o mesmo banco de dados de configuração para compartilhar metadados, definições de configuração e informações sobre todos os sites do IIS em que o SharePoint foi estendido no web farm. Por outro lado, aplicativos Web podem ser associados a um ou mais bancos de dados de conteúdo (ainda que cada um deles só possa ser associado a um aplicativo Web).

A relação entre sites do IIS, aplicativos Web, conjuntos de sites, sites e bancos de dados de conteúdo pode ser confusa. Na terminologia do SharePoint, o termo aplicativo Web se refere a um site do IIS com o SharePoint estendido. Um aplicativo Web pode incluir vários conjuntos de sites e cada conjunto pode, mais uma vez, incluir um site de nível superior e sites de níveis inferiores que compartilham as mesmas definições de configuração.

Dentre outras coisas, a criação de vários conjuntos de sites permite delegar a administração do conjunto de sites a usuários e grupos diferentes. Um único conjunto de sites não pode incluir vários bancos de dados de conteúdo, mas um aplicativo Web pode usar vários bancos de dados de conteúdo em vários conjuntos de sites para aumentar a escalabilidade e atenuar o impacto sobre o desempenho de um site grande que gera um volume significativo de atividade de banco de dados em outros sites do SharePoint. No entanto, não é boa idéia colocar todos os sites do SharePoint em seu próprio conjunto porque essa forma de implantação limita a funcionalidade entre sites.

O WSS 3.0 não dá suporte a pesquisas de conteúdo em vários conjuntos de sites. Elas exigem o MOSS 2007 ou o Microsoft Search Server 2008. Por exemplo, é possível criar um aplicativo Web e o site de nível superior para http://contoso, e o administrador de um conjunto de sites pode criar sites de nível inferior usando a interface do usuário do SharePoint como, por exemplo, http://contoso/info e http://contoso/events. Todos esses sites estão no mesmo banco de dados de conteúdo porque pertencem ao mesmo conjunto de sites.

Como administrador de um farm, você também pode usar um caminho gerenciado como, por exemplo, /sites e, em seguida, definir conjuntos de sites como http://contoso/sites/IT e http://contoso/sites/HR na Administração Central do SharePoint 3.0. Esses três conjuntos de sites (http://contoso, http://contoso/sites/IT e http://contoso/sites/HR) podem ter administradores, definições de configuração e bancos de dados de conteúdo diferentes, mas continuam todos sendo acessados por meio do mesmo site do IIS (http://contoso) e usam a mesma identidade do pool de aplicativos do aplicativo Web.

É claro que há muito mais detalhes, mas é especialmente importante compreender essa relação entre o IIS, o ASP.NET e o SQL Server para se sentir confortável em relação ao SharePoint. Caso você esteja interessado em ler mais sobre a arquitetura do SharePoint, recomendo o artigo "Descubra aprimoramentos significativos feitos para o desenvolvedor no SharePoint Services", de Ted Pattison, publicado na MSDN® Magazine e disponível em msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview.

Elementos da infra-estrutura do SharePoint

Agora traduzamos a nossa breve discussão sobre a arquitetura em uma infra-estrutura do SharePoint flexível. Como você certamente deve ter percebido, precisamos do Windows Server®, do IIS, do .NET Framework 3.0 (para o ASP.NET e o Windows® Workflow Foundation), do WSS 3.0 ou do MOSS 2007 e do SQL Server. Embora seja possível aguardar o IIS 7.0 no Windows Server 2008, usaremos o IIS 6.0 no Windows Server 2003, tendo em vista os nossos propósitos, porque no momento da redação deste artigo, trata-se da versão mais implantada. Continuaremos com o WSS 3.0 porque não precisamos de nenhum recurso específico do MOSS 2007 para um piloto inicial do SharePoint.

Em uma abordagem minimalista, é possível instalar o WSS 3.0 com todos os componentes obrigatórios em um único computador (como descrito no WSS 3.0, em single computer.pdf, disponível no material complementar desta coluna), o que é bom o bastante para um servidor em laboratório ou um ambiente de grupo de trabalho pequeno. No entanto, caso pretenda se concentrar na flexibilidade da infra-estrutura do SharePoint, você não deve começar com uma implantação autônoma no ambiente de produção. Tendo em vista a disponibilidade, bem como a futura escalabilidade, é melhor começar com uma infra-estrutura em várias camadas e adicionar mais servidores conforme necessário.

A Figura 4 mostra a infra-estrutura do SharePoint que recomendo caso você esteja em busca de uma configuração de sistema bem simples e flexível. Ela inclui um web farm dos dois servidores do SharePoint e um computador separado com o SQL Server em execução. Essa configuração elimina a sobrecarga do processamento do banco de dados nos servidores Web, aumenta a disponibilidade, a escalabilidade, além de facilitar a manutenção do sistema. Observe que você realmente precisa do Active Directory® por se tratar de um requisito de software do WSS 3.0 na implantação de um web farm. Para obter instruções passo a passo quanto à implantação, consulte o arquivo Basic SharePoint Infrastructure.pdf no material complementar.

Figure 4** Basic SharePoint infrastructure that can accommodate future growth **(Clique na imagem para aumentar a exibição)

A conta de domínio que você usa para implantar o SharePoint nessa disposição exige as permissões de um administrador local nos servidores Web. Também é necessário adicionar essa conta às funções do SQL Server dbcreator e securityadmin, bem como à função db_owner do banco de dados mestre no SQL Server 2005, como mostrado em Basic SharePoint Infrastructure.pdf. Em seguida, é possível usar o Assistente de Configuração de Produtos e Tecnologias do SharePoint durante a instalação do WSS 3.0 para criar o banco de dados de configuração necessário ao farm de servidores Web e um banco de dados de conteúdo para o site de Administração Central do SharePoint 3.0. Do contrário, um administrador do SQL Server deve provisionar esses bancos de dados para você e adicionar as contas de sistema do WSS à função db_owner.

É importante se lembrar de que a conta de usuário que você usa para instalar o SharePoint não é a conta que o SharePoint usa para acessar os bancos de dados de configuração ou de conteúdo do site de Administração Central. Na verdade, o SharePoint usa a conta de sistema configurada como sendo a identidade do pool de aplicativos do site de Administração Central do SharePoint 3.0.

O Assistente de Configuração de Produtos e Tecnologias do SharePoint solicitará a você as informações da conta. É uma boa idéia usar uma conta de usuário de domínio dedicado para isso como, por exemplo, CONTOSO\WssConfigAdmin. A minha prática geral tem sido usar contas de usuário individuais, dedicadas, para todos os aplicativos Web adicionais criados por mim antes. Usar um pool de aplicativos separado para cada aplicativo Web ajuda a garantir o isolamento do processo e o uso de uma conta de usuário diferente para cada pool de aplicativos ajuda a manter o isolamento da segurança. Porém, deve-se observar que se trata de apenas uma abordagem, e a capacidade de gerenciamento e o impacto potencial sobre o desempenho devem ser avaliados em relação ao próprio ambiente e aos requisitos comerciais.

Outra conta de sistema importante que um administrador de domínio deve criar para você é a conta do serviço de pesquisa. É possível usar a conta da Administração Central, mas tendo em vista a segurança agregada, é melhor usar uma conta de pesquisa dedicada como, por exemplo, CONTOSO\WssSearch, que não tem nenhuma permissão administrativa e que não pode modificar nenhum conteúdo. As permissões de gravação nos bancos de dados de conteúdo não são necessárias porque o serviço de pesquisa só rastreia conteúdo para fins de indexação e mantém os dados da pesquisa em um banco de dados separado.

Ao criar um aplicativo Web em um farm de servidores, você pode associar esse banco de dados de conteúdo a um servidor de pesquisa, que adiciona implicitamente a conta do serviço de pesquisa correspondente à diretiva Leitura Completa do aplicativo Web. Os servidores de pesquisa são servidores do SharePoint que executam o serviço Pesquisa do Windows SharePoint Services. Caso tenha seguido as instruções passo a passo do arquivo Basic SharePoint Infrastructure.pdf file, você configurou ambos os servidores Web como servidores de pesquisa e, dessa forma, é possível distribuir a carga do rastreamento e da indexação de vários bancos de dados de conteúdo. No entanto, também é possível configurar um servidor de pesquisa dedicado em um web farm, excluído do balanceamento de carga e das conexões de cliente para que estas não sejam afetadas por atividades de rastreamento.

Gerenciamento de sites de auto-atendimento

Com uma infra-estrutura do SharePoint básica in-loco, podemos delegar a administração dos conjuntos de sites e dos sites a departamentos individuais e a usuários sem descentralizar o controle administrativo sobre o Active Directory, o farm de servidores Web ou os bancos de dados do SQL Server. Como um administrador do farm, você colabora com os administradores do Active Directory e do SQL Server para provisionar contas do pool de aplicativos e bancos de dados de conteúdo para os aplicativos Web. Nesses aplicativos Web, você acaba criando conjuntos de sites e designando a administradores desses conjuntos o direito de criar sites de nível inferior. Dessa forma, os administradores de conjuntos de sites dentro de departamentos individuais podem gerenciar os recursos do SharePoint com um mínimo de envolvimento do departamento de TI, como ilustrado na Figura 5.

Figure 5** Decentralized site administration in a centralized SharePoint infrastructure **(Clique na imagem para aumentar a exibição)

Também é possível dar aos usuários a possibilidade de criar conjuntos de sites em caminhos gerenciados (como, por exemplo, o caminho /sites ou outros caminhos gerenciados com inclusões curingas criadas por você na Administração Central do SharePoint 3.0). Caso você habilite o recurso Self-Service Site Management em um aplicativo Web, os usuários podem criar conjuntos de sites próprios e gerenciar grupos de sites e permissões na interface do usuário do SharePoint. Diferentemente dos sites de nível inferior, os conjuntos de sites não herdam as permissões de um site pai.

O Self-Service Site Management não é apropriado a qualquer ambiente do SharePoint, permanecendo desabilitado por padrão. Caso o habilite, você pode acabar tendo um grande número de conjuntos de sites usados com pouca freqüência nos bancos de dados de conteúdo. No entanto, esse recurso demonstra bem a flexibilidade da administração do SharePoint, e recomendo que você o verifique na implantação do piloto. (Além disso, existem opções no SharePoint para notificar usuários e/ou administradores a respeito de sites inativos para que estes possam ser removidos se necessário.) Você deve habilitar o Self-Service Site Management para um aplicativo Web explicitamente, conforme descrito no arquivo Enabling Self-Service Site Management.pdf do material complementar.

Personalizações e identidade visual do SharePoint

Recursos do SharePoint

• TechCenter do Windows SharePoint Services
• Windows SharePoint Services Developer Center
• Blog da equipe de produtos e tecnologias do Microsoft SharePoint
• Componentes da arquitetura lógica
• Projetar farms de servidores e topologias

A esta altura, é um desejo natural incluir o logotipo da empresa, o nome e as cores comerciais na interface do usuário do SharePoint. Porém, lembre-se de que você está prestes a migrar o projeto do SharePoint para o nível de desenvolvedor do ASP.NET. No mínimo, você precisa de um sistema de desenvolvimento como, por exemplo, um servidor do WSS 3.0 autônomo com o Microsoft Office SharePoint Designer 2007 (consulte SharePoint Designer Installation.pdf no material complementar) para que seja possível criar e testar as personalizações sem afetar o ambiente do produto. Além disso, você deve visitar o Windows SharePoint Services Developer Center em msdn2.microsoft.com/sharepoint para saber mais sobre a abundância de opções em personalização oferecidas pelo SharePoint.

Embora o desenvolvimento do SharePoint esteja fora do escopo desta coluna, me permita indicar alguns aspectos que você deve levar em consideração. O SharePoint armazena páginas personalizadas no banco de dados de conteúdo do conjunto de sites correspondente. Em outras palavras, todas as personalizações aplicadas a páginas do site, páginas do aplicativo, páginas mestras, folhas de estilos etc. em um site do SharePoint só são aplicadas no nível do conjunto de sites ou do site. Isso é ótimo para administradores de conjuntos de sites individuais que desejam ajustar a aparência de seus sites usando o SharePoint Designer 2007, mas não tão bom assim para o administrador do farm que deseja impor a identidade corporativa em todos os aplicativos Web, conjuntos de sites e sites em um Web farm.

É possível criar temas ou definições de site personalizados com base em uma cópia de um tema ou definição de site do SharePoint padrão. Também é possível criar páginas mestras personalizadas e adicioná-las à Galeria de Páginas Mestras. No entanto, nenhuma dessas opções impõe a identidade visual global caso Self-Service Site Management esteja habilitado porque um usuário com as permissões para criar conjuntos de sites ou sites ainda pode selecionar um modelo de site padrão que não mostra a identidade corporativa.

A identidade visual global exige que você substitua os componentes do SharePoint padrão para que os componentes personalizados sejam usados em seu lugar. Os desenvolvedores percorrem grandes distâncias para conseguir isso sem modificar os arquivos originais. Uma abordagem é alterar a configuração dos diretórios virtuais no Gerenciador do IIS e apontá-los para novas pastas com arquivos personalizados. Outro método é implementar um módulo HTTP personalizado ou filtro ISAPI que reescreve as URLs a fim de redirecionar as solicitações de páginas padrão específicas para versões personalizadas.

Conclusão

Concentrei-me nas informações gerais do estabelecimento de uma infra-estrutura do SharePoint com o WSS 3.0. Não abordei outros recursos como, por exemplo, fluxos de trabalho, pesquisas, integração do sistema de mensagens e antivírus, nem funcionalidade específica do MOSS 2007 como, por exemplo, portais, diretórios de sites e catálogos de dados corporativos. As personalizações da administração do site e da identidade visual da empresa também abordam apenas as possibilidades dentro do SharePoint. É possível realizar mais personalizações com o WSS 3.0 programando aplicativos personalizados no Visual Studio®.

A infra-estrutura é eficiente o bastante para lidar com crescimento futuro caso você adicione mais servidores Web ou servidores de banco de dados. E, com a distribuição piloto de algumas personalizações, os usuários podem criar sites individuais e normalmente se familiarizam com o SharePoint. Dessa forma, você estabelece os componentes básicos da adoção do usuário, bem como o hardware e o software, que são flexíveis o suficiente para acomodar a alteração e servem de base para uma distribuição completa da produção.

Pav Cherny é especialista em TI e autor especializado em tecnologias Microsoft para colaboração e comunicação unificada. Entre suas publicações estão white papers, manuais de produto e livros com foco nas operações de TI e na administração do sistema. Pav é presidente da Biblioso Corporation.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..