Criar a arquitetura lógica dos sites de colaboração

Atualizado em: 2009-04-23

Neste artigo:

• Sobre sites de equipe em um ambiente de intranet

• Recomendações de design dos sites de equipe

• Hospedar sites de equipe em um aplicativo Web dedicado

• Planejar configurações gerais do aplicativo Web

• Escolher se os usuários podem criar conjuntos de sites

• Criar configurações de banco de dados de conteúdo para sites de equipe

• Excluir automaticamente sites que não são usados

• Usar caminhos para organizar URLs de site de equipe

• Planejar elementos personalizados

• Planejar permissões a serem aplicadas a sites de equipe

No Microsoft Office SharePoint Portal Server 2003, os sites de equipe tinham funcionalidade limitada quando comparados aos sites de portal. Isso não acontece no Microsoft Office SharePoint Server 2007. No Office SharePoint Server 2007, os sites colaborativos em um ambiente de intranet poderão aproveitar os mesmos recursos que um site de portal de intranet publicado, se os recursos forem disponibilizados no ambiente de intranet. Neste artigo, vamos nos referir a esses sites pelo termo anterior, "sites de equipe". No entanto, lembre-se de que esses sites não estão restritos aos recursos da versão anterior. Em vez disso, o termo "sites de equipe" significa que esses sites são usados por grupos menores ou para colaboração mais ad-hoc, ao contrário de um site de portal de intranet publicado e controlado.

Os sites de equipe são uma parte importante na maioria das implantações do Office SharePoint Server 2007 e são particularmente importantes nas implantações de intranet. A colaboração que os sites de equipe permitem e o espaço de armazenamento que fornecem são úteis para projetos de longo e curto prazo, comunicação e colaboração entre grupos. Se você planeja oferecer sites de equipe como parte da sua implantação, deve incluí-los no design de arquitetura inicial, para poder planejar a hospedagem e o gerenciamento dos sites. Por exemplo, você precisa planejar os bancos de dados de conteúdo necessários para hospedar o conteúdo do site de equipe, planejar o arquivamento e a exclusão dos sites de equipe de projeto de curto prazo para abrir espaço para mais projetos e monitorar os sites de comunicação da equipe a fim de garantir que o tamanho deles seja gerenciável para fins de backup e recuperação.

Este artigo fornece recomendações de design de arquitetura lógica para implantação de sites de equipe em um farm de servidores. Este artigo não aborda a arquitetura de informações, ou seja, a estrutura interna, dos sites de equipe. Para obter informações sobre a criação da arquitetura de informações, consulte Planejar estrutura e publicação de sites (Office SharePoint Server). Para obter mais informações sobre sites de equipe, consulte Planejar sites de colaboração.

Sobre sites de equipe em um ambiente de intranet

Em um ambiente de intranet do Office SharePoint Server 2007, os sites de equipe podem ser conectados ao seu site de portal de intranet publicado listando-os no Diretório de Sites. Você pode criá-los por meio do Diretório de Sites do site publicado para que possam compartilhar o mesmo nome de host ou pode apenas adicionar sites já existentes ao Diretório de Sites a fim de agregar todos os sites de equipe relacionados em um local. Não importa as URLs deles, eles podem aparecer como parte do portal de intranet publicado dessa maneira.

Como os sites de equipe são sites do SharePoint que têm o mesmo conjunto de recursos que qualquer site publicado em seu ambiente, eles também podem usar business intelligence, formulários e outros recursos disponíveis em seu ambiente. Esses recursos podem influenciar a arquitetura dos sites de equipe. Por exemplo, se você precisar exibir dados corporativos do catálogo de dados corporativos em um site de equipe, deverá garantir que os membros desse site de equipe tenham acesso à exibição dos dados. Os recursos de business intelligence e a segurança são configurados no nível do provedor de serviços compartilhados (SSP); portanto, todos os sites de equipe que se conectam aos mesmos dados corporativos devem usar o mesmo SSP e devem estar nos aplicativos Web associados a esse SSP.

Para obter mais informações sobre como planejar business intelligence e formulários em seu ambiente, consulte os seguintes recursos:

• Planejar business intelligence

• Planejar o InfoPath Forms Services

Recomendações de design dos sites de equipe

Na maioria das organizações, o número de sites de equipe aumenta e os tamanhos desses sites também, às vezes bem rapidamente. À medida que as equipes são reorganizadas ou os projetos concluídos e novos projetos iniciados, as equipes criam novos sites e abandonam os antigos ou expandem os sites de equipe atuais para que contenham cada vez mais dados. Para gerenciar ou controlar esse aumento, você precisa planejar cuidadosamente o seu suporte aos sites de equipe.

As metas de design dos sites de equipe incluem:

• Otimizar o desempenho do farm de servidores geral.

• Criar divisões lógicas de bancos de dados dos sites de equipe para manutenção contínua (ou seja, backup, recuperação e atualização).

• Permitir que você aplique diretivas e configurações apropriadas aos sites de equipe, sem afetar outros tipos de site da intranet.

A orientação de design dos sites de equipe inclui as recomendações a seguir, cada uma delas elaborada nas seguintes seções:

• Hospedar sites de equipe em um aplicativo Web dedicado.

• Aplicar configurações gerais de aplicativo Web, como configurações de gerenciamento de cota e ciclo de vida no nível do aplicativo Web para gerenciar o crescimento dos sites de equipe e manter o conteúdo atualizado.

• Criar configurações de banco de dados de conteúdo para armazenamento e dimensionamento apropriados e para garantir que você possa fazer o backup e restaurar bancos de dados do tamanho designado.

• Excluir automaticamente sites que não são usados.

• Usar caminhos para organizar URLs de site de equipe.

• Planejar políticas e permissões adequadas.

Hospedar sites de equipe em um aplicativo Web dedicado

Hospedar sites de equipe em um aplicativo Web dedicado ou em um aplicativo Web compartilhado com Meus Sites. Não recomendamos a hospedagem de sites de equipe no mesmo aplicativo Web que um site de portal de intranet publicado. Manter os sites de equipe separados do site de portal de intranet facilita a recuperação e a manutenção dos dados. (Se você gerenciar o tamanho dos bancos de dados de conteúdo, o problema será menor.) A ilustração a seguir mostra o aplicativo Web que contém os sites de equipe de uma solução de intranet:

Talvez seja conveniente usar vários aplicativos Web dedicados para hospedar seus sites de equipe. Considere os seguintes exemplos:

• Uma empresa de pesquisa de ações e investimentos dos Estados Unidos precisa manter os sites da divisão de investimentos e da divisão de pesquisa de ações completamente isolados para obedecer às normas da Comissão de Valores Mobiliários e Câmbio dos EUA. Neste exemplo, a empresa precisa usar dois aplicativos Web com conjuntos isolados de sites de equipe para as duas divisões. A empresa também precisa usar diretivas de aplicativo Web e SSPs separados para garantir que os usuários de cada divisão não vejam o conteúdo produzido pela outra divisão.

• Uma empresa de pesquisa e produção precisa manter controle rigoroso de suas descobertas de propriedade intelectual e pesquisa. Neste exemplo, a empresa pode hospedar os sites de equipe de pesquisa em um aplicativo Web separado e usar as diretivas desse aplicativo para impor permissões e garantir que apenas a equipe de pesquisa veja o conteúdo desses sites.

• Uma organização hospeda sites de equipe internos (intranet) e externos (extranet) e deseja implementá-los e gerenciá-los de maneira diferente. Neste exemplo, a organização planeja e implementa dois aplicativos Web separados para hospedar os dois conjuntos de sites, para que possa ter métodos de autenticação, bancos de dados e logs do IIS diferentes para cada ambiente, caso haja um problema. Para obter mais informações sobre como planejar extranets, consulte Projetar uma topologia de farm de extranet (Office SharePoint Server).

Em termos gerais, use os aplicativos Web para:

• Separar conteúdo anônimo de conteúdo autenticado.

• Isolar usuários.

• Impor permissões.

• Otimizar o desempenho.

• Otimizar a capacidade de gerenciamento.

Para obter mais informações sobre como decidir se deve ter aplicativos Web compartilhados ou dedicados, consulte Modelo de arquitetura lógica: implantação corporativa.

Considerar o desempenho

Ao hospedar sites de equipe em um aplicativo Web dedicado, você tem vários bancos de dados de conteúdo que contêm apenas conjuntos de sites de equipe. Se os bancos de dados de conteúdo hospedarem sites com características de dados semelhantes, o software de banco de dados Microsoft SQL Server funcionará de maneira mais eficiente, pois o SQL Server escolhe um plano de consulta com base nas características do banco de dados. Por outro lado, se um banco de dados hospedar sites com características de dados muito diferentes, o plano de consulta que o SQL Server usa talvez não seja o método mais eficiente para todo o conteúdo do banco de dados. Por exemplo, se um banco de dados hospedar sites de equipe (ou seja, um grande número de sites de tamanho médio) e sites de portal (ou seja, um pequeno número de sites bem grandes com muitas solicitações), o plano de consulta escolhido será ineficiente para um dos tipos de site. Portanto, ao colocar conteúdo dos sites de equipe em bancos de dados dedicados, você otimizará o desempenho do SQL Server, o que resultará em melhor desempenho do farm de servidores como um todo.

Considerar a capacidade de gerenciamento

Hospedando sites de equipe em um aplicativo Web dedicado, você pode aprimorar a capacidade de gerenciamento das seguintes formas:

• Pode gerenciar separadamente os seguintes itens:

  • Configurações do banco de dados

  • Modelos de cota

  • Configurações da Lixeira

  • Ações automatizadas para sites não usados

  • Autenticação

  • Diretivas

• Pode gerenciar com mais eficiência o crescimento dos sites de equipe, gerenciando sites de equipe separadamente dos outros tipos de site.

• Pode criar a oportunidade de negociação de um contrato de nível de serviço específico. Por exemplo, juntamente com seu contrato de nível de serviço para armazenamento de backups semanais completos e backups diferenciais diários dos bancos de dados de conteúdo, você pode oferecer retorno mais rápido da recuperação de itens individuais do conteúdo usando a Lixeira de segundo estágio.

Escolher um pool de aplicativos

Em um ambiente corporativo, os sites de equipe podem compartilhar um pool de aplicativos com os aplicativos Web que tenham requisitos semelhantes de colaboração e isolamento. Por exemplo, os sites de equipe podem compartilhar um pool de aplicativos com Meus Sites, pois ambos são usados para colaboração, para armazenar informações e documentos e, geralmente, têm escopo semelhante para fins de isolamento (ou seja, estão ambos disponíveis para a organização toda).

Em geral, você precisa de um pool de aplicativos dedicado quando precisa fazer o seguinte:

• Separar conteúdo autenticado do conteúdo anônimo.

• Isolar aplicativos que armazenam senhas para interação com aplicativos de negócios externos (por exemplo, Catálogo de Dados Corporativos).

• Isolar aplicativos nos quais os usuários tenham maior liberdade para criar e administrar sites e para colaborar com os conteúdos.

Para obter mais informações sobre quando ter pools de aplicativos dedicados, consulte Modelo de arquitetura lógica: implantação corporativa.

Em um ambiente de hospedagem no qual o conteúdo de várias organizações é hospedado em um único farm de servidores, recomendamos a hospedagem de todo o conteúdo de uma única organização no mesmo pool de aplicativos. Isso traz uma melhor escalabilidade (com menos pools de aplicativos, você tem menos processos em execução), bem como isolamento de processo entre os pools de aplicativos (para que, se o pool de aplicativos do Cliente A parar, isso não afete os sites do Cliente B). Isso, obviamente, depende do número de organizações que você tem, de suas recomendações de planejamento de desempenho e de seus requisitos de isolamento.

Planejar configurações gerais do aplicativo Web

Há várias configurações na página Configurações Gerais do Aplicativo Web que podem auxiliá-lo no gerenciamento do aumento de dados e do conteúdo atual dos sites de equipe do seu ambiente. Essas configurações aplicam-se a todos os sites de um aplicativo Web. No mínimo, planeje implementar as configurações a seguir (cada uma delas será abordada posteriormente, nesta seção):

• Defina e aplique um modelo de cota para limitar o tamanho máximo dos sites de equipe.

• Estabeleça um tamanho máximo de carregamento. Escolha um tamanho generoso com base nos requisitos da empresa para que os usuários possam colaborar com facilidade.

• Ative as Lixeiras do site e use a Lixeira de segundo estágio.

Além das configurações relacionadas anteriormente, avalie as configurações de todos os recursos da página Configurações Gerais do Aplicativo Web para garantir que os recursos sejam apropriados aos sites de equipe de sua organização. Por padrão, os seguintes recursos estão habilitados:

• Marca inteligente do nome da pessoa e status online (são exibidas informações de presença online)

• Alertas (os usuários podem criar até 500 alertas, por padrão)

• RSS Feeds (Really Simple Syndication)

• Interface de programação de aplicativo (API) de blog (link para criar um blog)

Determinar configurações de modelo de cota

Não há um modelo de cota padrão para sites de equipe em um ambiente do Office SharePoint Server 2007 No entanto, as seguintes configurações são recomendadas como ponto de partida:

• Um email automatizado é enviado ao proprietário do site quando o tamanho do site atinge 450 megabytes (MB).

• Os usuários são impedidos de carregar documentos adicionais quando o tamanho de um site atinge 500 MB.

Essas configurações podem funcionar bem em sua organização, mas você deve avaliar o tamanho e o número de itens que os usuários armazenarão nos sites de equipe e ajustar essas configurações conforme apropriado para garantir que os sites de equipe sejam usados como pretendido em sua organização.

Por exemplo, se sua organização inclui equipes de pesquisa ou design que colaboram entre si e produzem um grande volume de conteúdo que precise ser armazenado e arquivado, considere a possibilidade de aumentar os limites de cota; por exemplo, aumente o limite para 5 ou 10 gigabytes (GB). Nesses cenários, a hospedagem do conteúdo em sites de equipe garante o backup regular do conteúdo e a contribuição individual. Talvez também seja conveniente considerar a colocação de um conjunto de sites de 5 a 10 GB em seu próprio banco de dados de conteúdo, especialmente se você espera que o conjunto de sites aumente rapidamente.

Por outro lado, se seus sites de equipe forem usados principalmente para projetos de curto prazo ou comunicação da equipe, considere o uso de um limite de cota menor. Isso encorajará as equipes a armazenarem apenas as informações necessárias a fim de manter o avanço dos projetos de curto prazo (no entanto, procure não reduzir demais ou correrá o risco de um aumento dos custos associados às solicitações de aumento das cotas ao suporte técnico). Neste cenário, encoraje as equipes a armazenarem o conteúdo geral ou o conteúdo de um novo projeto em sites de equipe separados.

Se um site ou grupo específico de sua organização tiver uma necessidade corporativa de armazenar um volume maior de conteúdo no site da equipe, ajuste os limites de cota de um conjunto de sites individual. Para ajustar os limites de cota, na página Cotas e Bloqueios do Conjunto de Sites, selecione o conjunto de sites que corresponde à equipe ou ao grupo. Altere o modelo de cota atual para Cota Individual e, em seguida, especifique os limites apropriados.

Ao planejar modelos de cota, escolha limites adequados à maioria dos sites de equipe de sua organização. Para melhorar a capacidade de gerenciamento, só ajuste as cotas por usuário quando for necessário para atender a uma necessidade corporativa.

Determinar o tamanho máximo de carregamento

O tamanho máximo padrão de carregamento é de 50 MB. Esse valor é considerado um limite generoso que dá aos usuários a flexibilidade de carregamento de vários tipos e tamanhos de documento sem afetar negativamente o desempenho. Se os usuários de sua organização precisarem armazenar arquivos maiores nos sites de equipe, considere a possibilidade de ajustar essa configuração e procure monitorar as configurações de tempo limite do IIS, caso tenha usuários com conexões mais lentas.

Determinar configurações da Lixeira

Ativar a Lixeira é uma maneira simples de melhorar a capacidade de gerenciamento dos sites de equipe. A Lixeira permite que os proprietários do site recuperem itens excluídos sem intervenção administrativa central (ou seja, restauração das fitas de backup).

A lista a seguir descreve as configurações padrão da Lixeira, as quais funcionam bem para a maioria das organizações:

• Status da Lixeira: Ativada

• Excluir itens da Lixeira: Depois de 30 dias

• Lixeira de segundo estágio: Adicionar 50% da cota do site ativo para itens excluídos do segundo estágio

A Lixeira de segundo estágio armazena itens que os usuários excluíram de suas Lixeiras. Apenas os administradores de conjunto de sites podem restaurar itens da Lixeira de segundo estágio. O tamanho especificado para a Lixeira de segundo estágio aumenta o tamanho total do site de equipe. Por exemplo, se o limite do site de equipe for de 500 MB e a Lixeira de segundo estágio for definida como 50%, o valor total a ser usado pelo site será de 750 MB; portanto, planeje a capacidade de seu banco de dados de acordo.

Assim como na Lixeira, os itens contidos na Lixeira de segundo estágio são automaticamente excluídos quando o período de tempo para itens excluídos é atingido (30 dias, por padrão). No entanto, quando o limite de tamanho da Lixeira de segundo estágio é atingido, os itens dela são automaticamente excluídos começando pelos mais antigos. Os administradores de conjunto de sites também podem esvaziar a Lixeira de segundo estágio manualmente.

As principais considerações ao usar o recurso Lixeira são usar ou não a Lixeira de segundo estágio e o espaço que será alocado. Considere a possibilidade de alocar pelo menos uma pequena quantidade de espaço (como 10%) para a Lixeira de segundo estágio, caso um usuário exclua um documento importante, uma pasta de uma biblioteca de documentos ou uma coluna de uma lista por engano.

Planejar o método de criação do site

Você pode optar por criar conjuntos de sites para seus sites de equipe de forma central ou permitir que os usuários criem seus próprios conjuntos de sites, usando o Gerenciamento de Site Pessoal. Há vantagens e desvantagens em cada abordagem.

Se você permitir que as equipes criem conjuntos de sites por autoatendimento, elas poderão criar facilmente um site, quando necessário, sem assistência de um administrador. No entanto, há várias desvantagens nessa abordagem, incluindo:

• Você perde a oportunidade de implementar uma taxonomia eficaz.

• O gerenciamento do aplicativo pode ser dificultado.

• Os sites são facilmente abandonados.

• Você não pode compartilhar modelos e navegação em projetos ou equipes que podem compartilhar de algum modo um conjunto de sites.

Se, em vez disso, você criar conjuntos de sites de forma central, com base no modo de operação de sua organização, terá a oportunidade de implementar uma taxonomia completa que forneça a estrutura de gerenciamento e expansão dos sites de equipe. Também terá mais oportunidade de compartilhar modelos e navegação entre projetos e equipes que compartilham um conjunto de sites. Por essa abordagem, após a criação do conjunto de sites inicial, as equipes poderão criar sites dentro do conjunto de sites, conforme suas necessidades. Porém, você utilizará recursos de TI cada vez que um usuário quiser criar um site.

Para obter exemplos de quando usar cada método, consulte Modelo de arquitetura lógica: implantação corporativa. Para obter mais informações sobre como planejar a criação de um site, consulte Planejar o processo de criação de sites (Office SharePoint Server).

Se a sua organização optou por criar conjuntos de sites para os sites de equipe, em vez de permitir que os usuários criem seus próprios sites de equipe, use a Planilha de caminhos de site (em inglês) (https://go.microsoft.com/fwlink/?linkid=73149\&clcid=0x416) (em inglês) para determinar o nível de criação dos sites de equipe: sites de nível superior nos próprios conjuntos de sites ou um conjunto de sites grande com vários subsites. Para obter mais informações sobre como determinar a criação de vários conjuntos de sites ou de apenas alguns conjuntos de sites com vários subsites, consulte o tópico que o ajudará a decidir entre o uso de conjuntos de sites individuais ou subsites em um conjunto de sites, em Determine sites and subsites needed [Windows SharePoint Services], na Biblioteca Técnica do Windows SharePoint Services 3.0. Para obter mais informações sobre os tipos de site disponíveis no Office SharePoint Server 2007, consulte Determinar sites e subsites.

Criar configurações de banco de dados de conteúdo para sites de equipe

No artigo Modelo de arquitetura lógica: implantação corporativa, os sites de equipe são armazenados em bancos de dados dedicados, um para cada conjunto de sites. Essa abordagem permite a você gerenciar o banco de dados de cada conjunto de sites independentemente para backup, recuperação e migração. Além disso, quando um projeto é concluído, você pode arquivar facilmente os bancos de dados associados a ele. Embora você crie vários bancos de dados com o uso desta abordagem, também ganha a capacidade de controlar individualmente o banco de dados de cada conjunto de sites.

Lembre-se, no entanto, de que o desempenho do SQL Server pode ser afetado pelo número de bancos de dados em cada instância. Ou seja, se você pretende ter 300 ou mais conjuntos de sites de equipe, armazenar cada um deles em um banco de dados dedicado poderá reduzir o desempenho do SQL Server. Isso acontece porque cada banco de dados representa uma conexão entre o pool de aplicativos e o SQL Server. Quando você adiciona servidores Web e bancos de dados, o número de conexões ativas aumenta. Se você adicionar conexões em excesso, o SQL Server poderá deixar de responder.

Portanto, se você pretende ter mais de 300 conjuntos de sites de equipe, não deve usar bancos de dados dedicados. Em vez disso, armazene vários conjuntos de sites em cada banco de dados. Lembre-se de que 300 bancos de dados é o número usado pelo departamento de TI da Microsoft. Esses 300 bancos de dados não são um ponto de falha, mas uma estimativa baseada nos dados do SharePoint Portal Server 2003, onde 300 bancos de dados representavam um nível de confiança para a TI da Microsoft sobre quantos conjuntos de sites poderiam ser hospedados em cada servidor com segurança. Seu número vai variar conforme o número de parâmetros, incluindo o número de banco de dados. Por exemplo, o uso ou não de bancos de dados dedicados também pode depender de fatores como:

• As equipes têm contratos de nível de serviço diferentes (como requisitos de backup diferentes)?

• As equipes exigem mais de 8 GB de armazenamento?

• As equipe têm projetos com linhas do tempo diferentes? Misturar equipes com projetos curtos com equipes com projetos longos pode dificultar o arquivamento de sites e a movimentação deles fora do ambiente de produção, caso compartilhem o mesmo banco de dados.

• As equipes esperam um alto nível de autonomia e independência nas operações que ocorrem no nível do banco de dados?

Se responder sim a qualquer uma das perguntas acima, você deverá considerar o uso de bancos de dados dedicados para os conjuntos de sites.

Se você optar por armazenar vários conjuntos de sites em cada banco de dados, poderá calcular quantos irá armazenar em cada banco de dados, determinando o tamanho máximo de cada banco de dados e conjunto de sites (com base no valor limite de armazenamento do modelo de cota mais a alocação da Lixeira). Lembre-se de que, mesmo que atribua a todos cotas de 500 MB, nem todos usarão a cota total; portanto, talvez você crie bancos de dados de conteúdo em excesso. Considere a estimativa de cota ao planejar o banco de dados, mas não se esqueça de controlar o uso real e adaptar. Se você tinha um ambiente anterior com SharePoint Portal Server 2003 ou Windows SharePoint Services 2.0, também pode dar uma olhada no tamanho desses conjuntos de sites e criar bancos de dados baseados no tamanho real deles, em vez de nas estimativas de cota.

Em um ambiente gerenciado, os limites de tamanho do banco de dados são frequentemente determinados por estes dois fatores:

• O tempo necessário para fazer o backup de um banco de dados. Acima de um determinado tamanho de banco de dados, as operações de backup se tornam ineficientes, exigem mais tempo que o aceitável e ficam sujeitas a interrupções. Talvez esse também seja o ponto em que você decida adicionar mais servidores de banco de dados ao seu ambiente.

• A janela de serviço (isto é, a quantidade de tempo) permitida para restaurar o conteúdo, conforme determinado pelo acordo de nível de serviço. Por exemplo, se a janela de serviço para a restauração de conteúdo for de quatro horas, o tamanho do banco de dados será limitado a um volume que pode ser restaurado neste limite de tempo.

Para determinar o tamanho máximo de um banco de dados gerenciável para conjuntos de sites de equipe, determine os valores listados na tabela a seguir.

Dados dois valores de volume de conteúdo (B e D), o tamanho máximo gerenciável do banco de dados para sua organização será o menor entre os dois.

Depois de determinar o tamanho pretendido dos bancos de dados, calcule o número de conjuntos de sites que caberá em cada banco de dados. A tabela a seguir mostra o número de conjunto de sites por banco de dados com base no tamanho do banco de dados e nos limites de tamanho do conjunto de sites. Os limites de tamanho do conjunto de sites incluem o espaço alocado para a Lixeira de segundo estágio.

Ao criar o aplicativo Web para sites de equipe, modifique as configurações usando a página Gerenciar Bancos de Dados de Conteúdo para o primeiro banco de dados de conteúdo com o número máximo de conjunto de sites que corresponda aos limites de tamanho do banco de dados e do conjunto de sites (Número Máximo de Sites). Além disso, especifique o limite de número de sites que dispara um aviso (Aviso de Nível do Site). Quando o aviso de nível do site for alcançado, crie um novo banco de dados com as mesmas configurações. Quando o número máximo de conjuntos de sites for alcançado, nenhum novo conjunto de sites será criado no banco de dados. Se outro banco de dados não foi criado, a criação do site falhará.

Excluir automaticamente os sites que não são usados

Você pode aumentar o uso geral do conteúdo dos sites de equipe excluindo automaticamente os sites não usados. Isso pode ajudar a controlar o crescimento geral dos sites de equipe. Se os sites de equipe forem hospedados em um aplicativo Web separado, você poderá gerenciar os sites de equipe não usados de maneira diferente dos sites pessoais; por exemplo, dando a eles uma extensão de vida maior antes de começar a procurar sites não usados.

Por padrão, as configurações de exclusão automática dos sites não estão habilitadas. Para gerenciar as configurações de exclusão de site, na página Gerenciamento de Aplicativos, na seção Gerenciamento de Sites do SharePoint, clique em Confirmação de uso e exclusão de site.

Se você habilitar este recurso, as configurações padrão incluirão:

• Notificações são enviadas por email aos proprietários de conjuntos de sites 90 dias após sua criação ou confirmação de uso. Em outras palavras, se um site não for confirmado como usado dentro de 90 dias, seu proprietário receberá uma notificação.

• O sistema verifica se há conjuntos de sites não confirmados e envia avisos diariamente à meia-noite.

• A opção de exclusão automática de conjuntos de sites não confirmados não está selecionada. Se ela for selecionada, os sites serão automaticamente excluídos após o envio de 28 avisos. Como alternativa, você pode especificar o número de avisos.

Com base nas configurações padrão, um conjunto de sites que não tenha sido usado por 90 dias será excluído após 28 avisos ou 118 dias após a última confirmação do site. Você pode especificar as configurações apropriadas à sua organização. Como esse recurso funciona por meio de confirmações, e não controlando o uso real do site, você precisa planejar ausências inesperadas dos proprietários do site e não definir prazos curtos de expiração e exclusão dos sites. Além disso, procure sempre ter vários administradores de conjunto de sites para que tenha um administrador substituto para confirmar o uso do site, caso o administrador principal do conjunto de sites fique fora por um período de tempo prolongado.

A exclusão automática de sites pode ajudá-lo a controlar o ambiente, mas você corre o risco de perder aqueles dados corporativos essenciais que podem estar armazenados em um site que foi excluído automaticamente. Para reduzir esse risco, recomendamos:

• Exigir um contato secundário para todos os sites. Com isso, se o proprietário do site não estiver disponível ou sair da organização, haverá um contato disponível para confirmar se o site está sendo usado. Se você não tiver um contato secundário e reduzir o número de dias ou de avisos antes da exclusão de um site não usado, correrá o risco de excluir acidentalmente um site necessário. Implemente esta recomendação ao ativar o Gerenciamento de Site Pessoal ou como um processo corporativo de criação de conjuntos de sites na Administração Central.

• Arquivar sites antes da exclusão automática. Muitas organizações que implementam a exclusão automática de sites não usados também investem no desenvolvimento de uma ferramenta que arquive todos os sites antes de serem excluídos automaticamente para que possam ser facilmente restaurados se contiverem informações fundamentais da empresa. A alternativa é planejar o armazenamento dos bancos de dados de conteúdo por longo prazo caso um site que tenha sido excluído precise ser restaurado em algum momento.

Usar caminhos ou nomes de host para organizar URLs de site de equipe

Dependendo de sua organização e de como você está usando os sites de equipe, considere a possibilidade de usar caminhos para organizar as URLs de seus sites de equipe. Por exemplo, para ter URLs diferentes para sites de equipe associados a divisões diferentes, use URLs como http://nome_da_empresa/nome_da_divisão/sites ou http://nome_da_empresa/pesquisa/sites. Da mesma forma, você pode fazer a associação com um site de intranet publicado usando http://nome_da_intranet/sites_de_equipe. Se estiver usando o Gerenciamento de Site Pessoal, a URL padrão dos sites de equipe é http://nome_do_servidor/sites, mas você também pode criar uma inclusão de curinga para http://nome_do_servidor/equipe ou qualquer prefixo que preferir para seus sites de equipe.

Para obter mais informações sobre caminhos, consulte os seguintes recursos:

• Planejar sites de colaboração

• Determinar sites e subsites

• "Usando inclusões explícitas e de curinga para caminhos de URL" em Modelo de arquitetura lógica: implantação corporativa

• White paper: Criar soluções de hospedagem compartilhadas no Windows SharePoint Services (https://go.microsoft.com/fwlink/?linkid=86128\&clcid=0x416)

Você também pode criar sites nomeados pelo host se tiver sites de equipe que atendam a uma função maior em sua organização. Por exemplo, se o site de recursos humanos for um site de equipe e não fizer parte do site de intranet publicado, talvez seja conveniente criar um site de equipe nomeado pelo host para que receba o nome de http://siterh ou http://recursoshumanos.

Planejar elementos personalizados

As personalizações podem deixar seu ambiente mais complexo, particularmente quando estiver pensando em testar todos os pacotes de solução várias vezes: antes de implantá-los, quando precisar aplicar uma atualização e quando estiver pronto para atualizar o ambiente. Você deve decidir a diretiva da organização que será aplicada ao uso de recursos, modelos, Web Parts etc. personalizados e planejar a capacidade de gerenciamento, suporte e uso desses elementos em seu ambiente.

• Capacidade de gerenciamento   Se precisar fazer o backup e restaurar o ambiente todo (diante de um cenário de recuperação de desastre ou se estiver movendo o hardware), você precisará fazer o backup de todos os elementos personalizados (como uma Web Part personalizada que foi desenvolvida para seu ambiente ou uma definição de site personalizado) e não se esquecer de adicioná-los novamente ao ambiente quando restaurar. Isso é necessário porque não é possível restaurar o banco de dados de configurações, o qual contém todas as referências a esses elementos personalizados; portanto, você deve adicioná-los novamente ao ambiente restaurado. Por exemplo, você precisa adicionar novamente as definições de site personalizado e instalar as Web Parts personalizadas. Se você esquecer um elemento personalizado quando mover para um novo servidor ou restaurar um servidor, poderá causar erros nos sites de equipe dos usuários e precisará rastrear o código necessário enquanto os usuários aguardam.

• Capacidade de suporte   Ter elementos personalizados em seu ambiente pode aumentar o tempo de solução de problemas quando algo der errado. Cada parte personalizada do código é única, pode ser complexa ou simples e pode consumir memória adicional para ser executada. Considere o número de lugares em que o código personalizado é usado e o seu impacto no sistema. Além disso, considere como você pode excluir as personalizações como parte da causa raiz de um problema ao solucioná-lo. Se estiver criando o código personalizado, procure fazê-lo de forma a garantir que qualquer erro de suas personalizações seja registrado no log de eventos — para eventos do Microsoft Operations Manager (MOM) — e em qualquer outro local que sua organização use para solucionar problemas, para que você possa resolver os erros.

• Usabilidade   Considere a usabilidade de soluções, Web Parts e modelos. Se você tiver muitos modelos personalizados de sites de equipe em seu ambiente e a lista deles ocupar várias telas (por exemplo, 50 é um número excessivo para ler e diferenciar), procure verificar se você realmente precisa de todos esses elementos personalizados, se pode dividir a lista de alguma maneira ou se deve agrupá-los em pacotes de recursos comuns para facilitar a pesquisa e o rastreamento.

Algumas organizações optam por ter mais de uma diretiva de personalização. Por exemplo, elas podem optar por ter um sistema de duas ou três camadas, com o nível 1 para sites básicos (usando apenas modelos padrão), nível 2 para algumas personalizações (com um contrato de nível de serviço diferente) e nível 3 onde as organizações hospedam o hardware, mas a equipe que possui sites é responsável pela execução e pelo gerenciamento do ambiente personalizado desse hardware. Esse é outro caso no qual talvez seja conveniente ter vários aplicativos Web para hospedar os sites de equipe, com contratos de nível de serviço diferentes para cada aplicativo Web.

Planejar permissões a serem aplicadas a sites de equipe

As permissões e as diretivas que você aplica aos sites de equipe determinam:

• Quem pode criar sites de equipe.

• Quem pode exibir sites de equipe e contribuir com eles.

• Quem é impedido de acessar conteúdo nos sites de equipe.

Recomendamos usar grupos de segurança para gerenciar permissões. A tabela abaixo oferece orientações sobre a configuração de permissões e indica onde elas são configuradas.

Baixar este manual

Este tópico está incluído no seguinte manual baixável para facilitar a leitura e a impressão:

• Planejamento e arquitetura para o Office SharePoint Server 2007, parte 2

Consulte a lista completa de manuais disponíveis na página de download de conteúdo do Office SharePoint Server 2007.