Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar

Compreendendo as pastas padrão do EXOLEDB

Publicado em: 1 de fevereiro de 2006

By Jason Nelson

Este artigo descreve as diferentes pastas do EXOLEDB no servidor do Microsoft® Exchange e explica a finalidade delas.

Introdução ao EXOLEDB

O EXOLEDB cria algumas pastas do sistema em NON_IPM_SUBTREE durante a fase de aceitação de clientes da inicialização do MDB (banco de dados de mensagens). Algumas das pastas são mantidas por questões de histórico, mas a maioria tem finalidades práticas. Se as pastas forem excluídas, o servidor poderá ser afetado. Nenhuma dessas pastas deve ser replicada. As pastas criadas incluem:

  • \NON_IPM_SUBTREE\schema-root\

  • \NON_IPM_SUBTREE\schema-root\Default

  • \NON_IPM_SUBTREE\schema-root\Microsoft\

  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1

  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb

  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\controls

  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\img

  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\views

  • \NON_IPM_SUBTREE\StoreEvents\

  • \NON_IPM_SUBTREE\StoreEvents\GlobalEvents

  • \NON_IPM_SUBTREE\StoreEvents\Internal

  • \NON_IPM_SUBTREE\OWAScratchPad

Em todos os casos, as subpastas nomeadas com a GUID correspondem ao objeto MDB que tem a mesma GUID.

As primeiras pastas criadas são as pastas do esquema.

Schema-Root

A lista a seguir apresenta a pasta schema-root:

  • \NON_IPM_SUBTREE\schema-root\

    Essa foi introduzida no Exchange 2000 Server.

  • \NON_IPM_SUBTREE\schema-root\Default

    Essa foi introduzida no Exchange 2000 Server Service Pack 1 (SP1).

  • \NON_IPM_SUBTREE\schema-root\Microsoft\

    Essa foi introduzida no Exchange 2000 Server SP1.

  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1

    Essa foi introduzida no Exchange 2000 Server SP1.

A seguir há um caminho comum de esquema para um MDB público:

  • File://.BackOfficeStorage/<domínio>/<Nome_TLH>/NON_IPM_SUBTREE/schema-root/microsoft/exchangeV1

O caminho do esquema do MDB particular está sob a caixa de correio do Atendente do Sistema.

O EXOLEDB oferece suporte a vários esquemas ou definições de tipo de propriedade. Essas pastas oferecem suporte à plataforma de desenvolvimento de armazenamento na Web do Exchange. A idéia era que os itens da pasta pudessem fazer referência a várias versões do esquema e coexistissem. Em um determinado ponto do Exchange 2000 Server, os arquivos do esquema estariam na pasta raiz do esquema e as alterações seriam eficientemente propagadas para todos os itens. Como isso gerou problemas no espaço de trabalho de desenvolvimento do aplicativo, onde cada item precisava ser manipulado para remover ou adicionar propriedades conforme apropriado, a Microsoft adotou um método de controle de versão. Na pasta shema-root, a Microsoft cria subpastas com elementos do aplicativo e da versão para permitir atualizações diretas de forma eficiente. O EXOLEDB analisa as pastas do esquema em busca de alterações para poder propagar entradas, despejar o cache do esquema e repopular durante o processamento. A pasta \schemaroot\default é onde os itens normais de pasta obtêm seu esquema, e a pasta schema-root é sinalizada de forma a apontar para a pasta ExchangeV1. O EXOLEDB popula as entradas do esquema dos arquivos .xml, que são processados por um coletor de eventos, o EXSCHEMA.EXE. A ligação do coletor de eventos do esquema não pode ser excluída nem removida, pois ela não tem uma entrada na pasta EventBindings como a maioria dos eventos.

EXCHWEB, Views, IMG e Controls

A lista a seguir apresenta EXCHWEB, Views, IMG e Controls:

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\controls

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\img

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\views

Introduzidos no Exchange 2000 Server SP1, esses itens não foram populados no Exchange 2000 Server Service Pack 3 (SP3) e não são populados no Exchange Server 2003.

Para que o armazenamento local abra itens que fazem referência à funcionalidade de controle do Microsoft Outlook® Web Access, os arquivos devem estar em uma pasta que possa ser sincronizada. Essas pastas já contiveram cópias dos dados da Web do Outlook Web Access para permitir que os itens armazenados no LIS fossem abertos, mas nunca foram usadas fora do LIS.

Em seguida, o EXOLEDB inicia o sistema de ligação de eventos, que cria StoreEvents.

StoreEvents

Todas as pastas de evento de armazenamento descritas na lista a seguir estão presentes desde o Exchange 2000 Server:

  • \NON_IPM_SUBTREE\StoreEvents\

  • \NON_IPM_SUBTREE\StoreEvents\GlobalEvents

  • \NON_IPM_SUBTREE\StoreEvents\Internal

Essa é a pasta de ligação de eventos, na qual o EXOLEDB armazena informações sobre eventos criados para um MDB específico. Na inicialização, o EXOLEDB deve enumerar os eventos aqui, o que pode levar a um longo tempo de inicialização do armazenamento com um número grande de coletores de eventos. O desempenho do Exchange Server 2003 nessa área foi bastante melhorado, mas o tempo de montagem de um MDB ainda é afetado pelo número de linhas. Cada ligação é validada em relação à classe, tendo um método de evento válido, como onsave ou ontimer, clsid válido e parâmetros do coletor. Os eventos com uma classe ANY correspondente só podem ser registrados na subpasta GlobalEvents.

Depois de criar as pastas do esquema e de iniciar o sistema de ligação de eventos, o EXOLEDB cria o bloco de rascunho do Outlook Web Access.

OWAScratchPad

A OWAScratchPad foi introduzida no Exchange 2000 Server SP1. Ela aparece assim:

  • \NON_IPM_SUBTREE\OWAScratchPad

As postagens devem ser iniciadas em outro lugar para terem anexos e, para logons de armazenamento público, esse lugar é o bloco de rascunho do Outlook Web Access. Como o DAV não transpõe as operações do MDB, você precisa de um ponto em cada caixa de correio para gravação de postagens, a fim de poder oferecer suporte à adição de anexos. As postagens são armazenadas na OWAScratchPad até que todos os anexos sejam adicionados ou salvos. O limite de tamanho do bloco de rascunho do Outlook Web Access controla o tamanho dos anexos que podem ser adicionados por esse programa. Tentativas de publicar mensagens maiores resultarão no seguinte erro:

  • Este item excede o tamanho máximo definido para esta pasta e não pode ser salvo. Solicite ao administrador do servidor para aumentar os limites da pasta.

O tamanho de OWAScratchPad é sempre redefinido como 1 MB na inicialização do EXOLEDB quando o valor "Message Size Limit" da opção REG_DWORD da chave HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA do Registro não está definido. Isso é exigido pelo Microsoft SharePoint® Portal Server, pois o EXOLEDB não sabe se você está executando no modo "magma".

As postagens do Outlook Web Access no bloco de rascunho são feitas no formato simples de URL, ou seja, elas fazem referência diretamente à pasta e à mensagem. Isso é feito para oferecer suporte a vroots extensas, em que a URL amigável talvez seja longa demais.

Perguntas freqüentes sobre pastas do EXOLEDB

Considere as perguntas freqüentes a seguir.

O que causa a duplicação de pastas do sistema?

Há duas categorias para essa pergunta:

  • Objetos do Active Directory   Quando um armazenamento é excluído, não há como informar o Active Directory de que os objetos da pasta pública partiram. Então, quando as pastas são recriadas, elas não são anexadas aos objetos correspondentes do serviço de diretório. Novos objetos do serviço de diretório são criados.

  • Pastas reais   Se as pastas estiverem definidas para replicar e o armazenamento em questão for excluído, o EXOLEDB recriará as pastas na inicialização e a replicação poderá então criar uma segunda duplicata de qualquer uma dessas pastas. Isso causa problemas nas ligações de eventos. Excluir as pastas duplicadas por meio de URLs amigáveis é perigoso, pois as duas normalmente terão URLs amigáveis duplicadas.

Por que as pastas têm nomes estranhos?

Quando a quantidade de pastas do sistema com o mesmo número aumenta, um número aleatório é anexado ao proxy do serviço de diretório para torná-la exclusiva, resultando em nomes como controls12345678.

Por que não posso excluir pastas?

Se você excluísse as pastas, o EXOLEDB as colocaria de volta. Além disso, a maioria dessas pastas possui funções que afetarão negativamente a operação do servidor caso não estejam presentes.

Como corrigir pastas do esquema?

Se as pastas do esquema não estiverem presentes, ou seja, se não estiverem na subárvore ipm, definir a seguinte chave do Registro com um valor 0 para REG_DWORD fará com que o esquema seja populado novamente:

HKLM\System\CurrentControlSet\MSExchangeIS\Parameters\Schema\<MDBGUID>

Quais são as permissões usadas nas pastas do esquema?

O EXOLEDB concede automaticamente acesso de leitura às pastas do esquema a todos os usuários. Essa ACL (lista de controle de acesso) poderia ser modificada, mas seria excluída se a propagação do esquema fosse disparada novamente.

É preciso replicar essas pastas quando os servidores são descomissionados?

Não é preciso replicar o conteúdo da pasta como parte dos procedimentos de replicação de pastas do sistema.

Para obter mais informações

Para obter mais informações, consulte a seguinte entrada do blog do Exchange:

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft