Procedimentos de cópia de segurança e restauro offline para o Exchange

Traduções de Artigos Traduções de Artigos
Artigo: 296788 - Ver produtos para os quais este artigo se aplica.
Expandir tudo | Reduzir tudo

Nesta página

Sumário

Este artigo poderá conter hiperligações para conteúdo em inglês (ainda não traduzido).

Este artigo descreve métodos que pode utilizar para ignorar as interfaces de programação de aplicações (API, Application Programming Interfaces) de cópia de segurança online e efectuar uma cópia de segurança e restaurar manualmente as bases de dados do arquivo de informações do Exchange. Se tiver vários grupos de armazenamento num único servidor de Exchange, cada grupo tem de ser considerado como uma unidade independente e auto-suficiente em termos de cópia de segurança e restauro offline.Para obter informações adicionais sobre cópias de segurança offline e através de instantâneo, clique no número de artigo existente abaixo para visualizar o artigo na base de dados de conhecimento da Microsoft (KB, Microsoft Knowledge Base):
296787 XADM: Offline Backup and Restoration Procedures for Exchange Server 4.0, 5.0, and 5.5

Mais Informação

Antes de começar

Antes de efectuar uma cópia de segurança offline, certifique-se de que dispõe das seguintes informações:
  • Determine se o registo circular está ou não activado para o grupo de armazenamento. (No Exchange, o registo circular está desactivado por predefinição.) Para determinar se o registo circular está ou não activado, abra as propriedades do objecto do grupo_de_armazenamento no Exchange System Manager e, em seguida, visualize a página General. Para desactivar o registo circular, desmarque a caixa de verificação Circular Logging. As alterações ao registo circular não entram em vigor até parar todas as bases de dados do grupo de armazenamento.

    Não é necessário desactivar o registo circular para efectuar cópias de segurança offline. No entanto, tem de desactivar o registo circular se pretender reproduzir os registos de transacções em cópias de segurança offline restauradas.
  • Determine as localizações dos ficheiros de base de dados, transmissão em sequência, registo de transacções e de pontos de verificação do Exchange e o prefixo do ficheiro de registo do grupo de armazenamento.

    Para localizar estas informações, abra as propriedades do objecto do grupo_de_armazenamento no Exchange System Manager e, em seguida, visualize a página General. Anote os valores das seguintes caixas:
    • Log File Prefix (E0n, em que E0n pode ser E00, E01, E02 ou E03)
    • Transaction Log Location (E0n*.log)
    • System Path Location (E0n.chk)
    Os caminhos das bases de dados são listados nas propriedades de cada objecto nome_base_dados . Anote os valores dos seguintes campos, para cada base de dados do grupo de armazenamento:
    • Exchange Database (.edb)
    • Exchange Streaming Database (.stm)
Se o Exchange System Manager estiver indisponível, poderá encontrar todas as informações anteriores lendo os atributos directamente a partir do Active Directory, com uma ferramenta como o ADSIEDIT ou o LDIFDE. Pode utilizar o seguinte comando do LDIFDE para obter informações sobre todos os servidores do Exchange existentes numa floresta do Active Directory.

NOTA: o texto deste comando foi moldado para melhor legibilidade.
LDIFDE -F EXPATHS.TXT -D "CN=CONFIGURATION,DC=domínio_do_contentor_de_configuração,DC=domínio_de_nível_superior" -L MSEXCHESEPARAMLOGFILEPATH,MSEXCHESEPARAMSYSTEMPATH,
MSEXCHESEPARAMBASENAME,MSEXCHESEPARAMCIRCULARLOG,MSEXCHSLVFILE,
MSEXCHEDBFILE -R"(|(MSEXCHESEPARAMLOGFILEPATH=*)(MSEXCHESEPARAMSYSTEMPATH=*)(MSEXCHESEPARAMBASENAME=*)(MSEXCHESEPARAMCIRCULARLOG=*)(MSEXCHEDBFILE=*)(MSEXCHSLVFILE=*))"
Segue-se um exemplo do resultado do comando anterior:
D:\exchsrvr\mdbdata>ldifde -f con -d "cn=configuration,dc=teste,dc=com" -l msexch eseparamlogfilepath,msexcheseparamsystempath,msexcheseparambasename,msexchesepar amcircularlog,msexchslvfile,msexchedbfile -r "(|(msexcheseparamlogfilepath=*)(ms excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*)(msexchedbfi le=*)(msexcheseparamcircularlog=*))"
A ligar a "dc1.child.teste.com"
A iniciar a sessão como utilizador actual, utilizando SSPI
A exportar o directório para o ficheiro con
A procurar entradas...

<resultado truncado>

.dn: CN=First Storage Group,CN=InformationStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Excha nge,CN=Services,CN=Configuration,DC=Teste,DC=com
changetype: add
msExchESEParamCircularLog: 0 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.dn: CN=Public Information Store (EXCHANGE1),CN=First Storage Group,CN=Informati onStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Teste,DC=com
changetype: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

.dn: CN=Private Information Store (Exchange1),CN=First Storage Group,CN=Informat ionStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Teste,DC=com
changetype: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
Para reproduzir registos de transacções com êxito, tem de restaurar os ficheiros de base de dados (.edb e .stm) para as mesmas localizações a partir de onde foram incluídos na cópia de segurança. Por exemplo, se fizer uma cópia de segurança do ficheiro de base de dados a partir da pasta E:\Mdbdata e do ficheiro de transmissão em sequência da base de dados a partir da pasta F:\Mdbdata, tem de restaurar os ficheiros para E:\Mdbdata e F:\Mdbdata, respectivamente. Esta limitação aplica-se mesmo que pretenda restaurar a base de dados noutro servidor (por exemplo, numa situação de recuperação de caixa de correio única).

Se alterar o caminho de uma base de dados após a última cópia de segurança, apenas conseguirá reproduzir os registos de transacções parcialmente e apenas se alterar o caminho novamente para a localização original. Se reverter para o caminho antigo, apenas conseguirá reproduzir registos até ao ponto em que o caminho foi alterado.

Pode restaurar ficheiros de registo de transacções (E0n*.log) para um caminho diferente da localização original da cópia de segurança. Isto deve-se ao facto de os registos de transacções gravarem as localizações das bases de dados às quais estão anexados, ao contrário das bases de dados, que não gravam as localizações dos registos de transacções. Durante a reprodução, os registos "localizam" as bases de dados utilizando as informações de caminho armazenadas nos cabeçalhos dos registos de transacções. (A API de cópia de segurança online compensa internamente as alterações dos caminhos das bases de dados, pelo que esta limitação não se aplica.)

O utilizador não efectua a cópia de segurança nem restaura o ficheiro de pontos de verificação (E0n.chk), mas tem de saber a localização actual do mesmo, uma vez que poderá necessitar de examiná-lo ou eliminá-lo durante a recuperação.

Como se relacionam os ficheiros de base de dados do Exchange

Os ficheiros .edb e .stm são os repositórios finais para todas as informações da base de dados. Para a maioria das finalidades, encare estes dois ficheiros como se fossem um único; efectue a cópia de segurança destes ficheiros e restaure-os sequencialmente. Estes ficheiros devem estar sempre sincronizados cronologicamente, entre si; não é possível fazer corresponder um ficheiro .edb do qual seja feita uma cópia de segurança num determinado dia a um ficheiro de transmissão em sequência do qual tenha sido efectuada uma cópia de segurança noutro dia.

Um servidor de Exchange 2000 ou Exchange 2003 pode suportar até quatro grupos de armazenamento, podendo cada um destes suportar até cinco bases de dados. Um grupo de armazenamento é um grupo de bases de dados que partilham um conjunto comum de ficheiros de registo de transacções. O Microsoft Exchange Server 5.5 pode suportar, no máximo, um grupo de armazenamento, que suporta até duas bases de dados (os arquivos de informações privado e público).

À medida que são feitas alterações à base de dados, estas são escritas primeiro no ficheiro de registo de transacções e, em seguida, numa cache da memória. Assim que as alterações estiverem na cache, ficam visíveis a outros utilizadores. As páginas existentes na cache são descarregadas para o ficheiro da base de dados quando for conveniente. O ponto de verificação assinala, na sequência de ficheiros de registo, o ponto até ao qual todas as transacções já foram fisicamente descarregadas para o ficheiro da base de dados. A existência de um desfasamento de três ou mais ficheiros de registo entre o que contém o ponto de verificação e o ficheiro de registo actual é normal.

Para evitar confusões sobre quais os ficheiros que pertencem a cada grupo e armazenamento, é atribuído um prefixo exclusivo aos registos do Exchange que pertencem a um determinado grupo de armazenamento, constituído pelos primeiros três caracteres do nome de ficheiro. Os prefixos de registo válidos para os primeiros quatro grupos de armazenamento suportados num servidor de Exchange 2000 ou Exchange 2003 são E00, E01, E02 e E03. Ao longo deste artigo, o prefixo de registo para um grupo e armazenamento é designado por E0n. O ficheiro de registo actual para um grupo de armazenamento é sempre E0n.log.

Os registos de transacções têm, uniformemente, 5 megabytes (MB) de tamanho. Quando o ficheiro de registo actual está cheio, o respectivo nome é mudado para um número sequencial hexadecimal, denominado número de geração de registos, e é gerado um novo ficheiro de registo actual. Os ficheiros de registo são numerados como E0n00001.log, E0n00002.log, etc. Ao longo deste artigo, os ficheiros de registo numerados são designados genericamente por E0nxxxxx.log.

Se uma base de dados for parada anormalmente, o ficheiro de pontos de verificação (E0n.chk) grava o registo de transacções a partir do qual a recuperação deve iniciar a reprodução para restaurar a base de dados num estado de consistência. Este processo é designado por "recuperação de software". A "recuperação de software" pode ser encarada como o contraposto da "recuperação de hardware", que é o processo pelo qual os ficheiros de registo são reproduzidos depois do restauro de uma cópia de segurança online. A diferença mais importante entre a recuperação de software e de hardware é a intercalação de dados de um ficheiro patch no processo de reprodução do ficheiro de registo durante a recuperação de hardware.

Um ficheiro de base de dados do Exchange inconsistente é um ficheiro no qual ainda não foram escritas todas as transacções pendentes. Durante o funcionamento normal, os ficheiros de base de dados do Exchange estão inconsistentes dado que existem informações na cache que ainda não foram fisicamente escritas no ficheiro. Em geral, um ficheiro de base de dados do Exchange pode ser considerado consistente apenas após o encerramento normal do serviço de base de dados. Contudo, a base de dados, considerada como um todo (como a soma das informações existentes nos ficheiros de registo de transacções e de base de dados), está sempre consistente, a menos que sejam eliminados prematuramente ficheiros de registo necessários.

Efectuar uma cópia de segurança offline da base de dados do Exchange

Para efectuar uma cópia de segurança offline da base de dados do Exchange:
  1. Desmonte a base de dados da qual pretende efectuar a cópia de segurança. Não é necessário desmontar todas as bases de dados do grupo de armazenamento, apenas a base (ou bases) de dados da qual pretende efectuar a cópia de segurança.
  2. Verifique se os ficheiros da base de dados (os ficheiros .edb e .stm) estão consistentes e existe correspondência entre os mesmos. Para o fazer, execute o seguinte comando para cada ficheiro:
    eseutil /mh ficheiro_da_base_de_dados | find /i "DB Signature"
    NOTA: o Exchange 2000 Service Pack 2 e posteriores não comunicam o estado da base de dados como "consistente" ou "inconsistente", mas como "Clean Shutdown" ou "Dirty Shutdown". O significado de "Clean Shutdown" e de "consistente" é o mesmo, e o de "Dirty Shutdown" e de "inconsistente" também. No Exchange 2000 Service Pack 2 ou posteriores, execute este comando adicional para determinar o estado de cada base de dados:
    eseutil /mh nome_base_dados | find /i "Shutdown"
    Segue-se um exemplo do resultado do comando anterior:
    D:\mdbdata>eseutil /mh priv.edb | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    							
    No exemplo anterior, as assinaturas da DB são iguais, o que prova que os ficheiros .edb e .stm pertencem ao mesmo conjunto. (As linhas das assinaturas têm de ser completamente iguais, carácter a carácter, para que seja considerada uma correspondência.)

    Além da correspondência das assinaturas da DB, os ficheiros têm de estar sincronizados entre si e consistentes. Execute o seguinte comando para cada ficheiro:
    eseutil /mh ficheiro_da_base_de_dados | find /i "consistent"
    Segue-se um exemplo do resultado do comando anterior:
    D:\mdbdata>eseutil /mh priv.edb | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  04/04/2001 18:07:14
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "DB Signature"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  00/00/1900 00:00:00
    							
    No exemplo anterior, é indicado "State: Consistent" para ambos os ficheiros. Os números hexadecimais entre parênteses para cada ficheiro, (0x2CC7,1F14,1F7), também devem ser iguais. A marca de hora da última consistência não tem de ser necessariamente igual. Ambos os ficheiros estão consistentes e são correspondentes entre si.

    Se, para qualquer dos ficheiros, for indicado "State: Inconsistent" ou se as posições de registo da última consistência não estiverem sincronizadas, a base de dados não foi correctamente desmontada. Monte e desmonte novamente a base de dados. Se continuar a não existir uma correspondência correcta entre os ficheiros ou se estiverem inconsistentes, contacte o suporte técnico da Microsoft para obter assistência adicional.
  3. Copie os ficheiros .edb e os ficheiros .stm correspondentes para uma localização de cópia de segurança.
  4. Monte as bases de dados da cópia de segurança.
  5. Se o registo circular estiver activado, ignore este passo. Se o registo circular estiver desactivado e pretender efectuar um "roll forward" mais tarde, terá de efectuar uma cópia de segurança de todos os ficheiros de registo de transacções numerados (os ficheiros E0nxxxxx.log). Não crie uma cópia de segurança dos ficheiros E0n.log, Res1.log e Res2.log.

    Pode efectuar uma cópia de segurança dos ficheiros de registo numerados em qualquer altura que seja conveniente, mesmo imediatamente após a criação, uma vez que depois da mudança de nome de E0n.log para E0nxxxxx.log, o Exchange não torna a alterar o ficheiro. No entanto, elimine os ficheiros de registo com cópia de segurança apenas de acordo com as instruções do passo 6.

    As cópias de segurança dos ficheiros de registo não têm uma correspondência unívoca com as cópias de segurança da base de dados. A cópia de segurança de cada ficheiro de registo constitui um elo numa sequência de ficheiros de registo, que poderão ser reproduzidos em qualquer uma das diferentes cópias de segurança da base de dados. Pode efectuar o "roll forward" a partir de uma cópia de segurança específica da base de dados, desde que tenha uma sequência ininterrupta de registos, começada pelo registo listado na linha "Last Consistent" do cabeçalho da base de dados. Neste artigo, o registo da última consistência é referido como "registo âncora inferior".

    Se consultar o exemplo anterior, a entrada da última consistência é (0x2CC7,1F14,1F7). Os três números designam um ficheiro de registo, uma página nesse ficheiro e um deslocamento em bytes nessa página. Cada ficheiro de registo contém aproximadamente 10 000 páginas de 512 bytes cada. Este deslocamento de página é uma boa indicação do estado de preenchimento do ficheiro (o ficheiro de registo do exemplo anterior está com cerca de 80 % da capacidade preenchida, uma vez que 0x1F14 é equivalente ao decimal 7956), mas é irrelevante para a recuperação. A recuperação começa sempre no início do ficheiro.

    Neste exemplo, o ficheiro do registo âncora inferior é E0n02cc7.log.

    Poderá nem sempre ver o registo da última consistência no disco como um registo numerado, dado que este poderá ainda ter o nome E0n.log. Poderá ver o número sequencial que eventualmente será atribuído ao E0n.log examinando o cabeçalho do ficheiro de registo quando a base de dados estiver parada (o acesso ao cabeçalho de E0n.log é negado quando a base de dados estiver em execução).

    Para visualizar o número de geração de registos interno, execute o seguinte comando:
    eseutil /ml [ficheiro_de_registo] | find /i "lGeneration"
    Segue-se um exemplo do resultado do comando anterior:
    E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration"
          lGeneration: 11463 (0x2CC7)
    							
    Em muitas circunstâncias, é mais importante certificar-se de que as cópias de segurança dos ficheiros de registo estão em boas condições do que certificar-se das boas condições da cópia de segurança da base de dados. Isto deve-se ao facto de cada base de dados poder fornecer redundância relativamente a outras, mas uma recuperação completa de qualquer cópia de segurança da base de dados estar dependente da preservação de todos os ficheiros de registo posteriores a essa cópia de segurança.
  6. Ignore este passo se o registo circular estiver activado. Examine o cabeçalho do ficheiro de pontos de verificação para determinar qual o ficheiro de registo com numeração mais elevada que pode ser removido com segurança. O ponto de verificação controla o ficheiro de registo com menor numeração necessário para a recuperação automática, caso a base de dados seja parada anormalmente. Para examinar o ficheiro de pontos de verificação, execute o seguinte comando:
    eseutil /mk E0n.chk
    Segue-se um exemplo do resultado do comando anterior:
    D:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2CC7,9607,256)
    							
    A terceira linha, a linha do ponto de verificação, contém informações relevantes (a entrada LastFullBackupCheckpoint é utilizada pela cópia de segurança online e permanece a zeros se não for efectuada nenhuma cópia de segurança online da base de dados). O formato da posição do registo de pontos de verificação é igual ao da entrada da última consistência no cabeçalho da base de dados. Neste exemplo, o ponto de verificação está em E0002cc7.log.

    Se o registo circular estiver desactivado, os ficheiros de registo acumulam-se até serem manualmente eliminados ou removidos automaticamente pelo processo de cópia de segurança online. Se o registo circular estiver activado, não é necessária gestão especial de ficheiros de registo antigos, uma vez que o serviço de base de dados os elimina automaticamente depois da passagem do ponto de verificação pelos mesmos.

    Depois de efectuar cópias de segurança de todos os ficheiros de registo numerados, poderá recuperar espaço em disco removendo todos os ficheiros de registo numerados, excepto o registo de pontos de verificação.

    IMPORTANTE: não remova o registo de pontos de verificação.

    Neste exemplo, pode remover todos os registos até ao E0002cc6.log.
  7. Este passo é opcional. Pode usar o utilitário Esefile para verificar a integridade ao nível da página, das bases de dados copiadas.

    O ficheiro Esefile.exe está disponível na pasta Support do CD-ROM do Exchange Server 5.5 Service Pack 3, do CD-ROM de instalação do Exchange 2000 Server ou do Exchange Server 2003. Também pode obter o ficheiro Esefile.exe a partir do suporte técnico da Microsoft. O utilitário Esefile funciona com ficheiros .edb do Exchange Server 5.0 e 5.5, Exchange 2000 e Exchange 2003.

    Não existe actualmente outro método, além da cópia de segurança online, para verificar as somas de verificação de cada página de um ficheiro .stm. O ficheiro .stm contém dados não processados. Todos os índices e apontadores que organizam os dados estão no ficheiros .edb. Um problema no ficheiro .stm provoca a perda de alguns dados específicos do cliente, mas não compromete a integridade estrutural nem lógica da base de dados como um todo.

    Para verificar as somas de verificação de uma base de dados do Exchange, execute o seguinte comando do utilitário Esefile:
    esefile /s nome_base_dados
    Segue-se um exemplo do resultado do comando anterior:
    E:\mdbdata>esefile /s priv.edb
    
    Checksumming
    0    10   20   30   40   50   60   70   80   90  100
    |----|----|----|----|----|----|----|----|----|----|
    ...................................................
    
    23042 pages seen
    0 bad checksums
    241 uninitialized pages
    0 wrong page numbers
    
    esefile completes successfully after 10 seconds
    							
    Páginas não inicializadas são aceitáveis, mas numa base de dados sem problemas existem 0 somas de verificação com erros e 0 números de página errados.

    Se uma base de dados não passar a verificação de integridade do utilitário Esefile, a melhor opção será restaurar uma cópia de segurança anterior que tenha a certeza que se encontra em boas condições e efectuar um "roll forward" da base de dados. Caso não esteja disponível uma cópia de segurança com estas características, consulte o suporte técnico da Microsoft para saber como reparar ou recuperar a base de dados.
  8. Este passo é opcional. Pode utilizar o seguinte comando para verificar a integridade de ficheiros de registo com cópia de segurança:
    eseutil /ml E0n
    Segue-se um exemplo do resultado do comando anterior:
    k:\backups>eseutil /ml E00
    							
    Tem de executar este comando a partir de uma pasta que contenha os ficheiros de registo com cópia de segurança. Também pode executar este comando na pasta do registo actualmente em execução, mas se o Eseutil tentar ler o cabeçalho do E0n.log com uma base de dados do grupo de armazenamento em execução, receberá um erro -1032 (JET_errFileAccessDenied).

    Este comando detecta danos nos ficheiros de registo e também avisa se faltar um ficheiro de registo a meio da sequência ou se existir uma falha de correspondência de assinaturas entre os ficheiros de registo.

Restaurar uma cópia de segurança offline de uma base de dados do Exchange

Esta secção descreve dois métodos para restaurar uma cópia de segurança offline:
  • Restauro "point in time". Não são reproduzidos ficheiros na base de dados. Todos os dados criados após a cópia de segurança são perdidos.
  • Restauro "roll forward". Os ficheiros de registo criados depois da cópia de segurança são reproduzidos na base de dados. Se todos os ficheiros de registo estiverem disponíveis, todos os dados criados depois da cópia de segurança podem ser preservados. Se o registo circular estiver activado, terá de efectuar um restauro do tipo "point in time" da cópia de segurança offline; não pode optar por um restauro do tipo "roll forward".
O conjunto de ficheiros a restaurar deve obedecer aos seguintes critérios mínimos:
  • Para os restauros "point in time", todas as bases de dados paradas do grupo de armazenamento têm de estar consistentes e tem de existir um ficheiro de pontos de verificação válido. Não elimine o ficheiro de pontos de verificação actual ou quaisquer ficheiros de registo existentes.
  • Para todos os restauros "roll forward", todas as bases de dados do grupo de armazenamento têm de estar paradas e consistentes, e têm de existir todos os ficheiros de registo criados depois da criação da cópia de segurança (incluindo o E0n.log actual). O ficheiro de pontos de verificação tem de ser eliminado.
Se o conjunto de ficheiros não estiver de acordo com as condições anteriores, o restauro e a reprodução poderão não falhar, mas é provável que receba uma mensagem de erro -1216 (JET_errAttachedDatabaseMismatch) durante a recuperação de software.

Lidar com um erro -1216

Salvaguardas adicionais em relação à recuperação de software no Exchange 2000 e posteriores provocam o erro -1216 quando o Exchange detecta ficheiros de dados que tenham sido manipulados manualmente e determina que a execução da recuperação com o conjunto de dados actual resultaria em perda de dados anteriormente existentes.

Em versões anteriores do Exchange, se o conjunto de ficheiros estiver incompleto, mas for válido para uma reprodução com êxito, a recuperação de software é iniciada sem outros avisos ao administrador. No Exchange 2000 e posteriores, o administrador tem de ignorar especificamente o erro -1216 utilizando o Eseutil.

Restauro "point in time" de uma cópia de segurança offline

Para efectuar um restauro "point in time" de uma cópia de segurança offline:
  1. Se a base de dados que pretende restaurar estiver actualmente montada, desmonte-a. Se quaisquer outras bases de dados do grupo de armazenamento forem desmontadas, os ficheiros de base de dados e de transmissão em sequência (.edb e .stm) dessas bases de dados têm de estar consistentes e tem de existir correspondência entre os mesmos. (Para verificar a consistência e correspondência, consulte o passo 2 da secção "Efectuar uma cópia de segurança offline da base de dados do Exchange" deste artigo.)

    Se todas as bases de dados do grupo de armazenamento forem desmontadas, todas as bases de dados têm de estar consistentes e tem de existir um ficheiro de pontos de verificação válido. Um ficheiro de pontos de verificação válido é um ficheiro que tenha sido utilizado na última execução de qualquer base de dados do grupo de armazenamento, que tenha um cabeçalho que indique E0n.log como ponto de verificação. Se ainda existir uma base de dados montada no grupo de armazenamento, o ficheiro de pontos de verificação válido é o ficheiro actual, em utilização pelo sistema. Se ainda existir uma base de dados em execução, existe um ponto de verificação válido.

    Para verificar o ficheiro de pontos de verificação quando forem paradas todas as bases de dados, execute os seguintes comandos:
    eseutil /mk E0n.chk | FIND /i "checkpoint"
    eseutil /ml E0n.log | FIND /i "lgeneration"
    Segue-se um exemplo do resultado dos comandos anteriores:
    D:\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2cc7,1B59,1A)
    
    D:\mdbdata>eseutil /ml e00.log |find /i "lgeneration"
          lGeneration: 11463 (0x2cc7)
    							
    No exemplo anterior, o ponto de verificação está no registo com o lGeneration de 0x2cc7, que é e00.log. Assim, o ponto de verificação pode ser considerado válido.

    Se o ponto de verificação não for válido, poderá receber uma mensagem de erro -1216 (JET_errAttachedDatabaseMismatch) quando tentar montar qualquer base de dados do grupo de armazenamento. Este problema pode ocorrer mesmo que todas as bases de dados do grupo de armazenamento estejam consistentes.
  2. Copie os ficheiros .edb e .stm com cópia de segurança para as localizações adequadas dos ficheiros de base de dados e de transmissão em sequência. (Para encontrar estas localizações, consulte a secção "Antes de começar" deste artigo.) Verifique se os ficheiros restaurados estão consistentes e se existe correspondência.

    NOTA: se já existirem no servidor cópias dos ficheiros da base de dados que pretende restaurar, efectue uma cópia de segurança desses ficheiros antes de restaurar a base de dados, mesmo que os ficheiros existentes não possam ser iniciados. Estes poderão ser reparáveis e poderá conseguir recuperar dados a partir dos mesmos através do utilitário Exmerge.
  3. Monte a base de dados restaurada. A base de dados anexa-se ao final do ficheiro E0n.log. Depois do início da base de dados com êxito, não poderão tornar a ser reproduzidos, na mesma, ficheiros de registo anteriormente existentes. As bases de dados de pastas públicas que contêm milhares de pastas na hierarquia, poderão demorar algum tempo a ser iniciadas. Conte com, pelo menos, um minuto para cada 1000 pastas da hierarquia.

    Em versões anteriores do Exchange Server, era normalmente necessário executar o comando ISINTEG -patch depois de restaurar uma cópia de segurança offline de uma base de dados do arquivo de informações, para sincronizá-la com o directório. Quando é necessário aplicar um patch a uma base de dados do Exchange, a aplicação deste é efectuada automaticamente pelo sistema, a menos que a base de dados seja restaurada num servidor, grupo de armazenamento ou objecto de base de dados lógico diferente, ou se o objecto do Active Directory para a base de dados tiver sido eliminado e recriado no Active Directory. Nestes casos, é registada a seguinte mensagem de erro no registo de aplicações.
    Tipo de evento: Error
    Origem do evento: MSExchangeIS Mailbox Store
    Categoria do evento: General
    ID do evento: 1087
    Data: 5/4/2001
    Hora: 8:33:42 PM
    Utilizador: N/A
    Computador: EXCHANGE1
    Descrição: The information store was restored from an offline backup. In the Microsoft Exchange System Manager, indicate that the database "First Storage Group\Private Information Store" is allowed to be restored to, so that it can be patched.
    Para resolver este problema, tem de seleccionar a caixa de verificação This database can be overwritten by a restore no Exchange System Manager, nas propriedades da base de dados do respectivo objecto.

Restauro "roll forward" de uma cópia de segurança offline

Para aumentar as hipóteses de êxito na reprodução de ficheiros de registo numa base de dados restaurada:
  • Preserve uma cópia de todos os registos de transacções criados depois da cópia de segurança completa mais antiga.
  • Não altere um caminho de base de dados sem efectuar uma nova cópia de segurança completa imediatamente a seguir.
  • Não execute ESEUTIL /p ou ESEUTIL /d sem efectuar uma nova cópia de segurança completa imediatamente a seguir.
  • Não adicione nem remova uma base de dados de um grupo de armazenamento sem efectuar imediatamente uma cópia de segurança completa de todas as bases de dados do grupo de armazenamento.
Para iniciar o processo de restauro:
  1. Se a base de dados que pretende restaurar estiver montada, desmonte-a e, em seguida, copie os ficheiros de base de dados que pretende restaurar para os caminhos adequados no servidor. Se já existirem no servidor cópias dos ficheiros de base de dados que pretende restaurar, efectue uma cópia de segurança dessas cópias antes de restaurar a base de dados, mesmo que os ficheiros existentes não possam ser iniciados. Os ficheiros poderão ser reparáveis e poderá conseguir usar o utilitário Exmerge para recuperar dados a partir dos mesmos.
  2. Desmonte todas as bases de dados do grupo de armazenamento e execute o seguinte comando para cada base de dados do grupo de armazenamento actual e para cada ficheiro de base de dados restaurado:
    eseutil /mh nome_fich_base_dados | find /i "consistent"
    NOTA: o Exchange 2000 Service Pack 2 e posteriores não comunicam o estado da base de dados como "consistente" ou "inconsistente", mas como "Clean Shutdown" ou "Dirty Shutdown". O significado de "Clean Shutdown" e de "consistente" é o mesmo, e o de "Dirty Shutdown" e de "inconsistente" também. No Exchange 2000 Service Pack 2 ou posteriores, execute este comando adicional para determinar o estado de cada base de dados:
    eseutil /mh nome_base_dados | find /i "Shutdown"
    Segue-se um exemplo do resultado do comando anterior:
    D:\mdbdata>eseutil /mh PRIV.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  04/12/2001 20:07:46
    
    
    I:\mdbdata<eseutil /mh PRIV.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  00/00/1900 00:00:00
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  04/12/2001 20:07:41
    
    J:\mdbdata>eseutil /mh PRIV2.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  00/00/1900 00:00:00
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  04/12/2001 20:05:04
    
    K:\mdbdata>eseutil /mh PRIV3.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  00/00/1900 00:00:00
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  04/12/2001 20:07:43
    
    L:\mdbdata>eseutil /mh PRIV4.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  00/00/1900 00:00:00
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  04/12/2001 20:07:46
    
    M:\mdbdata>eseutil /mh PUB.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  00/00/1900 00:00:00
    							
    Este comando tem três finalidades:
    • Verificar se os ficheiros de base de dados estão todos consistentes.
    • Verificar se existe correspondência entre os ficheiros .edb e .stm de cada base de dados.
    • Identificar os ficheiros do registo âncora inferior e superior, que são o primeiro e último ficheiros necessários para recuperar todos os dados com êxito, sem gerar um erro -1216. O menor valor de última consistência de todas as bases de dados é o registo âncora inferior e o valor mais elevado é o registo âncora superior.
    No exemplo anterior, o ficheiro do registo âncora inferior é o E0002ac8.log e o ficheiro do registo âncora superior é o E0002cc7.log.
  3. Verifique se a assinatura do registo que está gravada no cabeçalho de cada base de dados é a assinatura do registo âncora inferior. Execute os seguintes comandos:
    eseutil /mh nome_base_dados | find /i "Log Signature"
    eseutil /ml reg_âncora_inferior | find /i "Signature"
    Segue-se um exemplo do resultado do comando anterior:
     <Formatting Type="Indent"><Formatting Type="FixedText"><![CDATA[
    D:\mdbdata>eseutil /mh priv.edb | find /i "Log Signature"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    
    D:\exchsrvr\mdbdata\save>eseutil /ml e0002ac8.log | find /i "Signature"
          Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
          Signature: Create time:12/29/2000 21:6:40 Rand:67798 Computer:
          Signature: Create time:12/29/2000 21:6:41 Rand:58314 Computer:
    							
    Um ficheiro de registo poderá indicar várias assinaturas. A primeira assinatura é sempre a própria; as restantes são bases de dados que estavam em execução na altura em que o registo foi criado. No exemplo anterior, as assinaturas dos registos que são gravadas nos ficheiros de base de dados não correspondem à assinatura de registo constante no registo âncora inferior.

    Se não conseguir localizar o registo âncora inferior, não conseguirá reproduzir registos na base de dados. Se não conseguir localizar o registo âncora inferior, não conseguirá reproduzir quaisquer ficheiros de registo em nenhuma base de dados. Existem dois métodos que pode utilizar para lidar com a falta de um registo âncora inferior:
    • Pode remover todos os ficheiros de registo. Uma vez que todas a bases de dados estão consistentes, pode iniciá-las sem a presença de qualquer ficheiro de registo, mas já não terá qualquer hipótese de recuperar dados ainda não existentes nos ficheiros de base de dados.
    • Pode remover bases de dados com os menores valores de última consistência, até poder criar uma sequência ininterrupta de registos a partir de âncoras inferiores ou superiores e, em seguida, executar a recuperação nas restantes bases de dados. Quando colocar as bases de dados removidas novamente no grupo de armazenamento, poderá reproduzir dados adicionais nas mesmas.
  4. Certifique-se de que as localizações actuais das bases de dados são as mesmas que antes de efectuar a cópia de segurança.

    Apesar de poder alterar o caminho do registo de transacções ou de trabalho depois de efectuar uma cópia de segurança, apenas poderá reproduzir ficheiros de registo se os ficheiros de base de dados estiverem nos mesmos locais a partir dos quais foram efectuadas as cópias de segurança. Se não tiver a certeza das localizações originais, execute o seguinte comando:
    eseutil /ml reg_"Last_Consistent" | find /i "nome ou padrão da base de dados"
    Segue-se um exemplo do resultado do comando anterior:
    N:\mdbdata>eseutil /ml e0002cc7.log |find /i ".edb"
          1 f:\MDBDATA\PRIV3.edb
          2 g:\MDBDATA\PRIV4.edb
          3 d:\MDBDATA\PRIV.EDB
          4 e:\MDBDATA\PRIV2.edb
          5 h:\MDBDATA\PUB.EDB
    
    d:\mdbdata>eseutil /ml e0002cc7.log |find /i ".stm"
            streaming file: k:\MDBDATA\PRIV3.stm
            streaming file: l:\MDBDATA\PRIV4.stm
            streaming file: i:\MDBDATA\PRIV.stm
            streaming file: j:\MDBDATA\PRIV2.stm
            streaming file: m:\MDBDATA\PUB.stm
    							
    NOTA: se o registo âncora for o E0n00001.log, não terá informações sobre caminhos no respectivo cabeçalho, uma vez que o cabeçalho do primeiro registo de uma sequência é gerado antes da anexação da base de dados ao registo. Neste caso, terá de verificar o cabeçalho do registo seguinte para ver informações sobre caminhos da base de dados. Em casos raros, isto poderá também acontecer em registos posteriores ao primeiro, devido à criação ou anexação de uma base de dados à sequência ininterrupta de registos, após a criação do registo.
  5. Reuna todos os registos, desde número da âncora inferior até ao maior número possível numa sequência ininterrupta, e copie estes registos para o caminho dos registos de transacções actuais. Não substitua registos que já estejam colocados no servidor sem efectuar previamente uma cópia de segurança dos mesmos. Para o fazer, poderá ter de restaurar ficheiros de registo a partir de mais do que um suporte de cópia de segurança.

    No exemplo anterior, a âncora inferior é o registo E0002ac8.log e a âncora superior é o registo E0002cc7.log. Quando examina registos disponíveis, o registo com numeração mais elevada poderá ter o número imediatamente abaixo do número necessário (por exemplo, E0002cc6.log em vez de 2cc7). Isto ocorre normalmente porque o E0n.log ainda não foi arquivado e ainda não foi mudado o respectivo nome para a numeração sequencial. Para determinar se o E0n.log é efectivamente o registo âncora superior, deve utilizar o comando que se segue para examinar o valor lGeneration existente no cabeçalho do ficheiro de registo:
    eseutil /ml E0n.log | find /i "lGeneration"
    Segue-se um exemplo do resultado do comando anterior:
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
          lGeneration: 11463 (0x2cc7)
    							
    NOTA: para ver o cabeçalho de um ficheiro de registo com o utilitário Eseutil, utilize o parâmetro /ml; para ver um cabeçalho de um ficheiro de base de dados, utilize o parâmetro /mh. Se trocar os parâmetros, os resultados dos comandos serão incorrectos.

    Normalmente, o registo âncora superior é também o registo mais elevado disponível, mas isto não será verdade se:
    • Os ficheiros de registo tiverem sido destruídos num desastre.

      - ou -
    • Estiver a restaurar todas as bases de dados do grupo de armazenamento ao mesmo tempo.
    No primeiro caso, é provável que encontre erros -1216 durante a recuperação; no segundo caso, poderá reproduzir ficheiros de registo, mesmo superiores ao registo âncora superior, desde que sigam a sequência lGeneration.
  6. Certifique-se de que todos os registos partilham a mesma assinatura e de que a sequência não está interrompida. Execute o seguinte comando:
    eseutil /ml E0n > nome_fich.txt
    Segue-se um exemplo do resultado do comando anterior:
    d:\mdbdata>eseutil /ml E00 > logverify.txt
    
    d:\mdbdata>type logverify.txt
    
    Microsoft(R) Exchange Server(TM) Database Utilities
    Version 6.0
    Copyright (C) Microsoft Corporation 1991-2000.  All Rights Reserved.
    
    Initiating FILE DUMP mode...
    
    Verifying log files...
          Base name: e00
    
          Log file: D:\exchsrvr\mdbdata\save1\E0000001.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000002.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000003.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000004.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000005.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000006.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000007.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000008.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000009.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000A.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000B.log
          Log file: D:\exchsrvr\mdbdata\save1\E00.log
    
    No damaged log files were found.
    
    Operation completed successfully in 3.305 seconds.
    							
    Este comando do Eseutil executa três acções: verifica a existência de danos nos ficheiros, comunica qualquer interrupção na sequência de ficheiros de registo e detecta diferenças nas assinaturas de registo.

    Todas as assinaturas de registos têm de ser iguais em todos os ficheiros de registo candidatos a reprodução. Tem de remover quaisquer registos que não tenham assinaturas iguais antes de iniciar a reprodução.

    Nesta altura, depois de remover os ficheiros que não passaram nos testes de verificação, os únicos ficheiros de registo de transacções existentes na respectiva pasta serão ficheiros que:
    • Fazem parte de uma sequência lGeneration ininterrupta, com início no ficheiro do registo âncora inferior e que termina, no mínimo, no ficheiro do registo âncora superior; quando possível, ultrapassa este último.
    • Têm assinaturas de registo iguais.
  7. Se o registo âncora superior ainda não tiver o nome E0n.log, mude-o.
  8. Remova o ficheiro E0n.chk da pasta System Path.

    Na ausência de um ficheiro de pontos de verificação, o Exchange Server começa a reproduzir os registos a partir do ficheiro de registo com numeração mais baixa disponível na pasta Transaction Logs: o registo âncora inferior. Se o ficheiro E0n.chk existir, o Exchange Server começa a reproduzir a partir do ponto de verificação gravado neste ficheiro. Se E0n.chk apontar para além do registo âncora inferior, a reprodução falhará completamente em relação ao conjunto de ficheiros restaurado. Em muitos casos, se se enganar no ficheiro de pontos de verificação, terá de reiniciar o restauro dos ficheiros de base de dados a partir da cópia de segurança.
  9. Como verificação final, antes de montar o grupo de armazenamento, certifique-se de que:
    • Todos os ficheiros de base de dados estão presentes nos respectivos caminhos de execução.
    • Os únicos ficheiros de registo existentes no caminho do registo de transacções em execução são ficheiros desde o registo âncora inferior até, pelo menos, ao registo âncora superior, com o ficheiro de maior numeração disponível designado por E0n.log.
    • Não existe um ficheiro E0n.chk na pasta System Path.
    Deverá agora conseguir montar o grupo de armazenamento com êxito e começar a reproduzir registos de transacções com este conjunto de registos. Mesmo depois da conclusão da recuperação e de a base de dados ser iniciada, poderão não ser recuperados todos os dados existentes em todos os ficheiros de registo devido a problemas de caminhos e de assinaturas de DB encontrados durante a reprodução. A secção "Lidar com falhas de correspondência de assinaturas e caminhos de bases de dados" deste artigo fornece informações adicionais sobre estes problemas.
  10. Se o arquivo de informações ainda não estiver em execução, inicie o mesmo e, em seguida, monte pelo menos uma base de dados no grupo de armazenamento. Isto fará com que a recuperação de software seja executada em todas as bases de dados do grupo de armazenamento.

    Em versões anteriores do Exchange Server, é normalmente necessário executar o comando ISINTEG -patch depois de restaurar uma cópia de segurança offline de uma base de dados do arquivo de informações, para sincronizá-la com o directório. Quando é necessário aplicar um patch a uma base de dados do Exchange, a aplicação deste é efectuada automaticamente pelo sistema, a menos que a base de dados seja restaurada num servidor, grupo de armazenamento ou objecto de base de dados lógico diferente, ou se o objecto do Active Directory para a base de dados tiver sido eliminado e recriado no Active Directory. Nestes casos, é registada a seguinte mensagem de erro no registo de aplicações.
    Tipo de evento: Error
    Origem do evento: MSExchangeIS Mailbox Store
    Categoria do evento: General
    ID do evento: 1087
    Data: 5/4/2001
    Hora: 8:33:42 PM
    Utilizador: N/A
    Computador: EXCHANGE1
    Descrição: The information store was restored from an offline backup. In the Microsoft Exchange System Manager, indicate that the database "First Storage Group\Private Information Store" is allowed to be restored to, so that it can be patched.
    Para resolver este problema, tem de seleccionar a caixa de verificação This database can be overwritten by a restore no Exchange System Manager, nas propriedades da base de dados do respectivo objecto.
Consulte o registo de eventos de aplicações no visualizador de eventos do Windows NT para verificar se foram detectados erros ou anomalias que possam ocorrer quando a base de dados for iniciada. É apresentado um evento 301 por cada ficheiro de registo reproduzido. Verifique atentamente a existência de erros e avisos durante o processo de recuperação.

Lidar com falhas de correspondência de assinaturas e caminhos de bases de dados

As bases de dados, à semelhança dos ficheiros de registo, têm as suas próprias assinaturas. No entanto, ao contrário das assinaturas dos registos, que não são alteradas após a criação do registo E0n000001.log, as assinaturas das bases de dados são alteradas sempre que a topologia física das mesmas é alterada, sem que estas alterações sejam registadas pelos ficheiros de registo. A desfragmentação ou reparação online de uma base de dados com o Eseutil altera a assinatura da DB. Após um evento deste tipo, a base de dados pode ser anexada à mesma sequência de registos, mas a base de dados não aceitará a reprodução de quaisquer transacções que tenham sido efectuadas quando a mesma ainda tinha a assinatura anterior. Uma cópia anterior da base de dados não aceitará a reprodução de quaisquer transacções que tenham sido efectuadas após a alteração da respectiva assinatura.

Devido a este modo de reposição de assinaturas de bases de dados, recomenda-se vivamente a criação de cópias de segurança completas da base de dados imediatamente após uma desfragmentação ou reparação offline. Se restaurar posteriormente uma cópia da base de dados com uma assinatura antiga, a reprodução é efectuada com êxito até à altura em que a assinatura foi alterada, mas perderá todas as alterações a partir desse ponto.

Se os caminhos de bases de dados forem alterados a meio de uma sequência de registos, o efeito é semelhante ao da alteração de assinaturas: a reprodução é interrompida na altura da alteração. (A API de cópia de segurança online fornece uma funcionalidade para remapear caminhos durante a recuperação; por este motivo, esta API pode reproduzir registos na totalidade, mesmo que tenha havido alteração de um caminho desde a criação da cópia de segurança.)

À medida que são encontrados problemas relacionados com caminhos ou assinaturas de DBs durante a reprodução, esses problemas são reportados no registo de eventos de aplicações, em linha com os eventos de reprodução 301 de cada ficheiro de registo. Os ficheiros de registo posteriores ao ponto do problema poderão parecer ser reproduzidos com êxito, mas isto deve-se apenas ao facto de o aviso de falha de correspondência não ser registado repetidamente. Como regra geral, a reprodução numa determinada base de dados é truncada a partir do ponto em que é encontrado o primeiro erro relacionado com caminhos ou assinaturas de DB, referente a essa base de dados.

Propriedades

Artigo: 296788 - Última revisão: 3 de dezembro de 2007 - Revisão: 4.6
A informação contida neste artigo aplica-se a:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Palavras-chave: 
kberrmsg kbhowto kbproductlink KB296788

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com