XADM: Como restaurar na chave do Registro progresso funciona

Traduções deste artigo Traduções deste artigo
ID do artigo: 200941 - Exibir os produtos aos quais esse artigo se aplica.
importante : Este artigo contém informações sobre como modificar o registro. Antes de modificar o registro, certifique-se de backup e certifique-se que você saiba como restaurar o registro se ocorrer um problema. Para obter informações sobre como fazer backup, restaurar e editar o registro, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
256986Descrição do registro do Microsoft Windows
Expandir tudo | Recolher tudo

Neste artigo

Sumário

A chave de registro do sistema de restauração em andamento é fundamental para restauração bem-sucedida de um backup on-line do Exchange Server. Este artigo aborda os seguintes tópicos:
  • A funcionalidade geral da chave do Registro.
  • A relação entre os arquivos de patch (.pat) para a chave do Registro.
  • Como remover com segurança essa chave do Registro, quando necessário.
  • Como criar essa chave do registro manualmente, quando necessário.
  • Como interpretar mensagens de erro que você pode receber quando o banco de dados é iniciado após você restaurar um backup online.

Mais Informações

Depois de restaurar um banco de dados de um backup online, sua seqüência de inicialização é diferente da inicialização do banco de dados comuns nos seguintes aspectos críticos três:
  • O processo é controlado por valores da chave do registro de restauração em andamento . O arquivo de ponto de verificação (EDB.chk) completamente é ignorado. Em essência, o valor de Número LowLog na chave do Registro atua como o ponto de verificação.
  • Arquivo de log pelo menos um deve ser executado no banco de dados. Arquivos de banco de dados que são restaurados de um backup on-line sempre são inconsistentes. Arquivos de log que são necessárias para tornar o arquivo de banco de dados consistente novamente são salvos na fita com o banco de dados e devem ser reproduzidos no banco de dados após a restauração, para que sempre haja pelo menos um arquivo de log em cada fita de backup on-line do Exchange Server. A chave de registro restauração em andamento lista o intervalo de arquivos de log restauradas a partir da fita.
  • Informações em arquivos de patch (* .pat) deve ser aplicado ao banco de dados junto com as informações dos arquivos de log restaurado. Informações de patch serão aplicadas apenas ao banco de dados se houver a chave de registro de restauração em andamento .
Este é o caminho para a chave de registro de restauração em andamento :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDS ou MSExchangeIS\Restore em andamento
Observação : A chave do Registro acima é um caminho; foram quebrada para facilitar a leitura.

Consistente versus arquivos de bancos de dados inconsistentes

Um arquivo de banco de dados do Exchange Server é considerado inconsistente se houver quaisquer transações presentes nos arquivos de log que ainda não tenham sido escritos para o arquivo de banco de dados. Isso significa que um arquivo de banco de dados sempre é inconsistente durante a operação normal. Como um backup online ocorre sem interromper a operação normal, o banco de dados salvo em fita é necessariamente inconsistente.

Durante um desligamento normal, o arquivo de banco de dados é feito consistente antes do serviço pára; todas as informações dos arquivos de log é aplicado ao arquivo de banco de dados. Conseqüentemente, quando você inicia o banco de dados em seguida, não há nenhuma informação de log precisa ser reproduzidos durante a inicialização. Se o banco de dados for interrompido inesperadamente, o arquivo de banco de dados é inconsistente e "recuperação simples" executa automaticamente durante a inicialização seguinte, para aplicar transações de log pendentes ao arquivo de banco de dados antes de ele é reiniciado.

O arquivo de ponto de verificação (EDB.chk) tem duas funções a seguintes:
  • O arquivo de ponto de verificação controla de quais transações registradas foram gravadas o arquivo de banco de dados. Em operação normal, o ponto de verificação pode latência por vários logs.
  • O arquivo de ponto de verificação fornece informações de que o processo de backup on-line precisa determinar quais logs devem ser colocadas em fita e quais logs podem ser com segurança removidos do disco após o backup completo.
Se o arquivo de ponto de verificação não estiver disponível após um banco de dados foi desligado em um estado inconsistente, o banco de dados examina todos os arquivos log disponíveis quando ele for reiniciado para determinar se os dados do arquivo de log tem ou não foi escritos para o arquivo de banco de dados. Exchange Server pode determinar com confiança quais transações já foram aplicadas. Se o arquivo de ponto de verificação é perdido nessa situação, inicialização simplesmente tempo.

importante : se você remove o arquivo de ponto de verificação e remover alguns arquivos de log manualmente, pode danificar o banco de dados se ele foi desligado em um estado inconsistente. Exchange Server precisa aplicar todas as transações pendentes log quando ele é reiniciado. Se apenas um subconjunto das transações pendentes log for encontrado, o subconjunto será aplicado mas não é suficiente para manter a integridade do banco de dados.

Nunca remova arquivos de log que não foram aplicados ao arquivo de banco de dados.

Para obter mais informações sobre como saber que arquivos de log são seguros remover, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
240145Como remover arquivos de log de transação do Exchange Server
Durante a operação normal, os logs de transação completamente descrevem todas as alterações feitas para o arquivo de banco de dados. Como o banco de dados for colocado em fita, as alterações podem ser feitas no banco de dados que afetam partes do arquivo já está bloqueada em fita. Nem todos os essas alterações podem ser capturadas nos arquivos de log. Essas alterações, portanto, são colocadas nos arquivos de patch.

Um arquivo de patch contém "instantâneos" de páginas específicas no arquivo de banco de dados. Como os logs de transação são repetidos em um arquivo de banco de dados restaurado, o Exchange verifica para ver se uma página descrita em um arquivo de log também existe no arquivo de patch. Em caso afirmativo, a versão do arquivo de patch é usada. Esse processo é chamado de "recuperação complexa" (em oposição à recuperação de software descrita acima).

Recuperação de disco rígida e a restauração na chave de registro de andamento

Quando um banco de dados restaurado foi concluída com êxito recuperação, a chave de registro de restauração em andamento será excluída automaticamente. Mas se uma inicialização não funcionar, a tecla permanece no registro. Ocasionalmente, talvez você precise excluir manualmente a chave após solucionar e resolver a causa de um problema de inicialização. É essencial que você não exclua a chave do registro antes de todo o arquivo de patch dados foi aplicados ao arquivo de banco de dados.

Se você excluir a chave de registro de restauração em andamento e o arquivo edb.chk, uma recuperação simples é executada em um banco de dados restaurado, que verifica e aplica a todos os logs disponíveis, mas sem o patch de informações do arquivo.

Portanto, se você remover a chave de registro de restauração em andamento , o banco de dados é garantido para ser corrompido, a menos que pelo menos uma das seguintes condições for atendida:
  • O arquivo de patch que coincide com o banco de dados está vazio.
  • Todos os os arquivos de log que são restaurados da fita de backup online completo já tem sido reproduzidos no banco de dados.
Um arquivo de patch "vazia" é 8 kilobytes (KB) de tamanho (ela tem duas páginas de cabeçalho de 4 KB, assim como um arquivo de banco de dados). Se você não forem reproduzidos o arquivo de patch em seu banco de dados, em seguida, para cada 4 KB extra no arquivo de patch, há uma página corrompida em seu banco de dados.

Você somente precisa patch dados de arquivo para copiar os logs provenientes de uma fita de backup total. Não é necessário o arquivo de patch para reproduzir arquivos de log adicionais de backups incrementais ou arquivos de log adicionais que existiam no disco antes de restauração. Se a inicialização do processo paradas trabalhando em um ponto depois que todos os dos logs de backup completo já foram jogadas e você excluir a chave do Registro restauração em andamento , você não causam danos dos dados de arquivo de patch perdidas.

No entanto, nem sempre é seguro excluir a chave de registro de restauração em andamento depois de eventos são registrados no log de eventos do aplicativo que indicam a repetição bem-sucedida de todos os logs da fita. A chave também remapeia e controles logon caminhos de arquivo durante a cópia e se os caminhos foram alterados entre a hora em que o backup foi feito e a hora em que foi restaurada, quando você excluir a chave que você pode ainda causar outros problemas ou talvez você não é possível repetir todos os dados de todos os logs.

No entanto, como regra prática, se a configuração de sistema do Exchange Server e caminhos não tem sido alterados após o backup foi feito, é geralmente seguro excluir a chave de registro restauração em andamento se você tiver certeza de que as informações dos arquivos de patch não é mais necessária.

Como saber se disco de recuperação foi concluída

Você pode determinar se todas a repetição do log que requer os arquivos de patch é concluída, executando as seguintes etapas:
  1. Para exibir o cabeçalho do arquivo .pat que corresponde ao banco de dados para determinar o intervalo de arquivos de log que foram restaurados da fita de backup total, execute o comando a seguir
    ESEUTIL /MH patch_file
    onde patch_file é o nome de arquivo do arquivo de patch, por exemplo:
    ESEUTIL /MH PRIV.PAT
    Observação : para o Exchange Server 4.0 e Exchange Server 5.0, use o comando EDBUTIL em vez do comando ESEUTIL . Parte da saída é semelhante ao seguinte:
    Current Full Backup:
            Log Gen: - 36-3f
               Mark: (58,1409,199)
               Mark: 8/19/1999 19:47:2
    							
    A linha de Log Gen sob a seção backup completo atual informa que arquivos de log chegar da fita de backup total. Nesse caso, arquivos de log Edb00036.log através de Edb0003f.log são do backup.
  2. Abra o Visualizar eventos Windows NT para determinar se todos os logs nesse intervalo já tem sido repetidos sem gerar erros. Todas as versões do Exchange Server geram eventos de repetição que contêm texto em suas descrições semelhante ao seguinte texto:
    O mecanismo de banco de dados é repetir o arquivo de log E:\Exchsrvr\Mdbdata\Edbxxxxx.log.
    Certifique-se de que um evento semelhante foi gerado para cada log da fita de backup total.
Mesmo se todos os logs da fita foi repetidos, exclua apenas a chave de registro restauração em andamento como um último recurso. Solucionar problemas para determinar a causa do problema de inicialização primeiro. Se você decidir excluir a chave de registro de restauração em andamento , salve uma cópia dele usando o programa Regedit.exe opção Exportar arquivo do Registro.

Restauração em andamento valores de chave de registro

Toda vez que o Exchange Server é iniciado, ele verifica a existência de uma chave de registro de restauração em andamento . Se uma for encontrada, uma recuperação de disco rígida será executada no banco de dados. Se a chave existir, mas os arquivos apropriados para recuperação de disco rígido (arquivos .pat e todos os logs de fita) não estiverem disponíveis, a inicialização do Exchange Server não funciona.

Depois de restaurar um backup online completo, sempre há um arquivo .pat na pasta de log de transação atual para cada arquivo de banco de dados foi restaurado. Também há pelo menos um arquivo de log numerado da fita. (O arquivo edb.log é nunca coloque em fita; se o arquivo edb.log existir após uma restauração do backup online, e estava presente no disco antes do backup foi restaurado.)

Se você compreender a chave de registro de restauração em andamento , melhor você compreender o processo de recuperação. Além disso, se você souber os valores que a chave deve conter, quando uma chave incorreta ou incompleta existe você pode detectar o problema.

A seguir é os valores na chave do Registro restauração em andamento :
  • LowLogNumber . Esse valor define o primeiro arquivo de log que deve ser repetido para uma disco rígida recuperação tenha êxito. Se você alterar esse número, uma recuperação de hardware não funcionará.
  • Número de HighLog . Esse valor é o arquivo de log numerado mais alto que foi restaurado da fita. Se vários backups forem restaurados (um backup completo mais um número de backups incrementais), o valor HighLog varia dependendo na ordem de restauração.

    Em geral, restaure backups em ordem cronológica, para que o valor HighLog reflete com precisão todos os logs da fita. Isso não é um requisito essencial; só é essencial que HighLog menos refletir o log numerado mais alto da fita de backup total.

    Mas se houver um problema nos arquivos de log, o Exchange Server o interpreta logs que serão restaurados da fita diferente logs são considerados já existem no disco. Visualizar eventos pode ter mais informativas recomendações sobre o que fazer para resolver um problema. Em alguns casos, os logs que são considerados já tenham sido no disco e que pode ser perigosa se repetidos podem ser excluídos sem aviso.
  • EDB_RstMap . Essa seqüência de valores múltiplos define "antes" e "após" caminhos convenção universal de nomenclatura (UNC) para os arquivos de banco de dados. Linhas ímpares na seqüência de caracteres são "antes" e até mesmo linhas são "após". Normalmente, Exchange Server não pode reproduzir arquivos de log para um banco de dados que foi movido do local de caminho original. Esse valor mapeia um caminho antigo para um novo caminho, que possibilita reproduzir mesmo se o banco de dados agora está em um servidor ou unidade que é diferente da unidade que foi feito o backup no. Se a chave de registro restauração em andamento malformada, esse valor é o mais provável que ter um problema. Se o antes e depois as seqüências de caracteres não coincidem, ter muito cuidado antes de excluir a chave do Registro restauração em andamento , porque se você excluir essa chave, pode ser impossível repetir dados suficientes para tornar o banco de dados consistente ou inicializável.
  • EDB_RstMap tamanho . Este valor corresponde ao número de bancos de dados anexados a um serviço. O valor é 1 ou 2. Para o serviço de diretório ou um servidor que é dedicado somente pastas particulares ou somente a pastas públicas, o valor é 1. Para um armazenamento de informações que possui bancos de dados públicos e particulares, o valor é 2. Esse valor multiplicado por 2 é o número de linhas no valor EDB_RstMap .
  • LogPath . Esse valor é um caminho UNC que aponta para a pasta de logs de transações atual para o servidor.
  • BackupLogPath . Esse valor é um caminho UNC que aponta para a pasta de logs de transações atual para o servidor. O valor BackupLogPath não aponta para o "antes" caminho local do log, porque não é crítico; apenas o local de caminho do banco de dados é o local original do caminho do log.
  • CheckpointFilePath . Esse valor é um caminho UNC que aponta para a pasta de trabalho caminho atual.
  • recuperados do banco de dados EDB . Imediatamente após a restauração do banco de dados, esse valor é 00. Após o Exchange Server com êxito tem repetidos todos os logs (se os logs foram restaurados a partir da fita ou já existia no disco) e iniciado o banco de dados, esse valor é alterado para 01. Em seguida, o banco de dados automaticamente desligado e inicia novamente. Quando o 01 valor é encontrado durante a inicialização, o serviço exclui a chave, em vez de obeying-lo. Se alterar esse valor para 01 manualmente, ele tem o mesmo efeito prático que excluir a chave de registro de restauração em andamento . Se esse valor for 01, é seguro excluir a chave do registro de restauração em andamento .

Como recriar uma restauração em andamento chave

Salve uma cópia da chave do Registro restauração em andamento antes de excluí-lo, em vez de tentar recriá-la. Somente use as instruções desta seção como um último recurso. Se você fizer um único erro de digitação ou qualquer outro erro ao criar a chave, a restauração não funciona.

É muito mais fácil de gerar uma chave de registro de restauração em andamento se você tiver um modelo para trabalhar. Na próxima vez que você tem acesso a essa chave do Registro, salvá-lo permanentemente do programa Regedit.exe antes de iniciar o banco de dados. Você pode simplesmente mesclar a chave do Registro e modificar valores específicos.

Para criar uma chave de registro válida restauração em andamento , você deve já restaurou o banco de dados, patch e arquivos de log de uma fita.

Cole a seguinte planilha em um editor de texto:
Transaction Logs Path:  
Working Path:  
Number of databases:  
Server from which backup was taken:  
Server to which backup is being restored:  
LowLog Number:  
HighLog Number:
					
Preencha a planilha com as seguintes informações:
  • O caminho atual para o banco de dados e os arquivos de log. Você pode exibir essas informações no registro.

    Para o serviço de diretório:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDS\Parameters (caminho de arquivos de log do banco de dados, arquivo de banco de dados do serviço de diretório, diretório de trabalho do serviço de diretório)
    Para o armazenamento de informações:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate (caminho do banco de dados)

    - e -

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersPublic (caminho do banco de dados)

    - e -

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem (caminho de log de banco de dados, pasta de trabalho)
    Observação : ele é uma boa idéia para documentar essas informações permanentemente para todos os computadores Exchange Server. Você pode fazer isso usando o programa Exchange Server Administrator. O objeto de Server para cada servidor registra os caminhos de dados local na página de propriedades Caminhos de banco de dados .
  • Os números de valor do LowLog e HighLog para o backup completo. Essas informações podem ser obtidas arquivo Priv.pat pelo procedimento descrito o "como para saber se rígido recuperação foi concluída" seção deste artigo.
  • Se os caminhos tiverem sido alterados desde o backup foi feito, você deve saber os locais de caminho de arquivo de banco de dados original. Você pode obter essas informações do log de transação LowLog usando o comando a seguir
    ESEUTIL /ML LowLog_file
    onde LowLog_file é o nome de arquivo log numerado mais baixo.

    A saída é semelhante à seguinte:
    E:\exchsrvr\mdbdata>ESEUTIL /ML EDB00036.LOG
    
    
          1 E:\EXCHSRVR\MDBDATA\PRIV.EDB
             dbtime: 326969 (0,0)
              objid: 76
          Signature: Create time:8/19/1999 19:37:35 Rand:39623424 Computer:
    DatabaseSizeMax: 0
          Last Attach (6,3111,100)  Last Consistent (0,0,0)
          2 E:\EXCHSRVR\MDBDATA\PUB.EDB
             dbtime: 3890 (0,0)
              objid: 105
          Signature: Create time:8/19/1999 19:37:36 Rand:39631469 Computer:
    DatabaseSizeMax: 0
       Last Attach (6,3575,345)  Last Consistent (0,0,0) 
    							
    Observação : A opção /ML somente está disponível para o Exchange Server 5.5 Service Pack 1 ou posterior. Se você estiver executando uma versão anterior do Exchange Server, você deve saber antecipadamente seus locais de caminho original.
  • Você deve saber o número de bancos de dados associadas ao serviço. No exemplo acima de um armazenamento de informações comuns, o número é dois.
  • Se você desejar restaurar o backup para um servidor diferente, você deve saber o nome do servidor original. Se você não souber o nome do servidor original, você não é possível obtê-lo facilmente dos dados de backup. O nome do servidor não está contido nos arquivos de armazenamento de informações. Se você tentar iniciar os arquivos de serviço de diretório em um servidor que tem o nome errado, os arquivos do serviço de diretório fazer uma mensagem de erro e o nome de servidor esperado do relatório em Visualizar eventos do Windows NT.
Depois de ter todas essas informações, você está pronto para criar a chave do registro de restauração em andamento :

Aviso : se você usar o Editor do Registro incorretamente, poderá causar problemas sérios que talvez exijam a reinstalação do sistema operacional. A Microsoft não garante que você pode resolver problemas resultantes do uso incorreto do Editor do Registro. Use o Editor do registro por sua própria conta e risco.

  1. Inicie o Editor do Registro (Regedt32.exe, não o Regedit.exe).
  2. Localize uma das seguintes chaves no registro, conforme aplicável:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDS

    - ou -

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS
  3. Selecione MSExchangeDS ou MSExchangeIS como aplicável e, em seguida, clique em Adicionar chave no menu Editar . Digite o seguinte nome de chave (diferencia maiúsculas de minúsculas):
    restauração em andamento
    Deixe a caixa de classe em branco e, em seguida, clique em OK .
  4. Para criar cada valor na chave, clique para selecionar restauração em andamento , clique em Adicionar valor no menu Editar e, em seguida adicione o seguinte registro valores (tipo o valor nomes exatamente e coincidir com as maiúsculas e minúsculas):
    nome do valor : BackupLogPath
    tipo de dados : REG_SZ
    seqüência de caracteres : \\ SERVERNAME \ D $ \ logpath

    Por exemplo:
    \\NEWSERVER\f$\Exchsrvr\Mdbdata
    nome do valor : CheckpointFilePath
    tipo de dados : REG_SZ
    seqüência de caracteres : \\ SERVERNAME \ D $ \ workingpath
    Por exemplo:
    \\NEWSERVER\c$\Exchsrvr\Mdbdata
    Nome do valor : banco de dados EDB recuperado
    tipo de dados : REG_BINARY
    formato de dados : hex
    dados : 00

    nome do valor : EDB_RstMap
    tipo de dados : REG_MULTI_SZ
    dados : \\ BACKUPSERVER \ D $ \ dbpath \ dbname edb
    \\ RESTORESERVER \ D $ \ dbpath \ dbname edb
    Por exemplo:
    \\OLDSERVER\c$\exchsrvr\MDBDATA\PRIV.EDB
    \\NEWSERVER\d$\exchsrvr\MDBDATA\PRIV.EDB
    \\OLDSERVER\c$\exchsrvr\MDBDATA\PUB.EDB
    \\NEWSERVER\e$\exchsrvr\MDBDATA\PUB.EDB
    Observação : se você restaurar dois bancos de dados, há quatro linhas no EDB_RstMap valor; uma linha "antes" e "após" para cada banco de dados. As linhas de cada par diferem somente se você tiver alterado servidores ou caminhos. Pressione a tecla ENTER no final de cada linha, exceto para a última linha.

    nome do valor : EDB_RstMap tamanho
    tipo de dados : REG_DWORD
    base : decimal
    dados : 1 ou 2

    nome do valor : número HighLog
    tipo de dados : REG_DWORD
    base : hex
    dados : número de log alta do arquivo .pat ou o maior número de log restaurado a partir de uma fita incremental.
    Por exemplo:
    3F
    nome do valor : LogPath
    tipo de dados : REG_SZ
    seqüência de caracteres : \\ SERVERNAME \ D $ \ logpath
    Por exemplo:
    \\NEWSERVER\f$\Exchsrvr\Mdbdata
    nome do valor : número LowLog
    tipo de dados : REG_DWORD
    base : hex
    dados : número de log inferior do arquivo .pat.
    importante : não insira qualquer outro número aqui.
    Por exemplo:
    36

Interpretar mensagens de erro durante a inicialização de um banco de dados restaurado

Muitos dos motivos a que um banco de dados restaurado não pode iniciar são semelhantes aos motivos que uma inicialização comum não funciona. Os códigos de erro são exibidos durante a recuperação de hardware são diferentes os códigos de erro que são exibidos normalmente. Se você pode correlacionar os códigos de erro recuperação de hardware com suas contrapartes de recuperação simples, você poderá encontrar artigos importantes e outros recursos que você pode ignorar caso contrário.

Se você iniciar um banco de dados restaurado a partir da linha de comando ou verifique em Visualizar eventos, são exibidos códigos de falha de decimal ou hexadecimal do seguinte formato:
335544nnnn

- ou -

0xc8000nnn
Durante a inicialização uma banco de dados comum, o mesmo erro teria formas a seguir:
42949nnnnn

- ou -

0xfffffnnn
Por exemplo, um dos mais comuns códigos de erro que podem ser exibidos após você restaurar um backup online é 3355443730 (decimal) ou 0xc8000212 (hexadecimal). Durante uma inicialização comum do banco de dados, mesmo esse erro é relatado como 4294966766 ou 0xfffffdee. Todos esses números de erro correspondem às-530 (JET_errBadLogSignature).

Observação : Error.exe O utilitário que está incluído em todas as versões do CD de instalação do Exchange Server pode traduzir códigos de erro entre formulários decimais e hexadecimais e pode fornecer representações de texto de muitos erros.

Se você inserir vários formulários de um código de erro (separados por ou ) em uma seqüência de pesquisa da Base de dados de Conhecimento da Microsoft, você aumentar bastante as chances de encontrar informações valiosas sobre as causas do código de erro.

Esteja ciente de que um único problema pode ser reportado como vários eventos sucessivos durante a inicialização, como vários subcomponentes no serviço relatar o problema independentemente. Esses vários códigos de erro fornecem informações adicionais sobre os módulos que são afetados pelo problema, mas pode ser confusos e pode levar você achar que há vários problemas. Se vários códigos de erro são exibidos em uma linha durante a inicialização, eles relatar mais provável que o mesmo erro.

Propriedades

ID do artigo: 200941 - Última revisão: sábado, 28 de outubro de 2006 - Revisão: 4.1
A informação contida neste artigo aplica-se a:
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Palavras-chave: 
kbmt kbinfo KB200941 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 200941
Aviso de Isenção de Responsabilidade sobre Conteúdo do KB Aposentado
Este artigo trata de produtos para os quais a Microsoft não mais oferece suporte. Por esta razão, este artigo é oferecido "como está" e não será mais atualizado.

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