Partilhar via

Notas de versão do Exchange 2013

  • Artigo

Aplica-se a: Exchange Server 2013

Bem-vindo ao Microsoft Exchange Server 2013! Este tópico contém informações importantes que você precisa saber para implantar com êxito o Exchange 2013. Leia este tópico completamente antes de iniciar a sua implantação.

Este tópico contém as seguintes seções:

  • Configuração e implantação

  • Shell de Gerenciamento do Exchange

  • Mailbox

  • Pastas públicas

  • Fluxo de mensagens

  • Conectividade de cliente

  • Coexistência do Exchange 2010

Configuração e implantação

  • msExchProductId não reflete a versão de versão do Exchange 2013 instalada Depois que o Exchange estende seu esquema do Active Directory e prepara o Active Directory para Exchange, várias propriedades são atualizadas para mostrar que a preparação está concluída. Uma dessas propriedades é msExchangeProductId no CN=<your organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<domain> contêiner no contexto de Configuration nomenclatura. Se nenhuma alteração de esquema do Active Directory for introduzida na versão do Exchange 2013 que você está instalando, essa propriedade não será atualizada ou poderá mostrar um valor inesperado. Isso poderá causar confusão se o valor não corresponder à versão do Exchange 2013 instalada.

    Esse comportamento é esperado, pois o valor de msExchProductId não reflete a versão do Exchange 2013 que está sendo instalada. Essa propriedade reflete a versão do Exchange 2013 que fez alterações pela última vez no esquema do Active Directory. Para evitar confusão, recomendamos que você siga as etapas na seção Como você sabe que isso funcionou? do Prepare Active Directory e domínios para verificar se o Active Directory foi atualizado e está pronto para o lançamento do Exchange 2013 que você está instalando.

  • A instalação solicita incorretamente .NET Framework 4.0: se você tentar instalar o Exchange 2013 sem .NET Framework instalado no computador, a instalação solicitará incorretamente que você instale .NET Framework 4.0 quando, de fato, .NET Framework 4,5 ou posterior é necessário.

    Para resolver esse problema, instale .NET Framework 4.5 ou posterior. Não é necessário instalar o .NET Framework 4.0. Para obter uma lista completa de pré-requisitos, consulte Pré-requisitos do Exchange 2013.

  • Os arquivos de configuração de aplicativo do Exchange XML são substituídos durante a instalação cumulativa da atualização: todas as configurações personalizadas do Exchange ou do Servidor de Informações da Internet por servidor que você fizer em arquivos de configuração de aplicativo do Exchange XML, por exemplo, web.config arquivos em servidores de Acesso ao Cliente ou no arquivo EdgeTransport.exe.config em servidores da caixa de correio, serão substituídos quando você instalar uma Atualização Cumulativa do Exchange ou o Service Pack. Não deixe de salvar essas informações para poder reconfigurar facilmente o servidor após a instalação. Você deve redefinir essas configurações depois de instalar uma Atualização Cumulativa ou um Service Pack do Exchange.

  • Instalar o Exchange usando permissões de Delegação Administração faz com que a Instalação falhe Quando um usuário que é membro apenas do grupo de funções de Configuração Delegada tenta instalar o Exchange em um servidor pré-provisionado, a configuração falhará. Isso acontece porque o grupo de instalação delegada não possui as permissões necessárias para criar e configurar determinados objetos no Active Directory.

    Para contornar esse problema, siga um destes procedimentos:

    • Adicione o usuário instalando o Exchange no grupo de segurança do Active Directory do Domain Admins.

    • Instale o Exchange usando um usuário que seja membro do grupo de funções Gerenciamento da Organização.

Para obter mais informações sobre como instalar o Exchange 2013, confira Planejamento e implantação.

Shell de Gerenciamento do Exchange

  • O Shell carrega inesperadamente cmdlets exchange 2007 ou Exchange 2010 Anteriormente, abrir o Shell em um servidor do Exchange 2013 resultaria na abertura do Shell de uma conexão com o servidor local ou outro servidor que executa o Exchange 2013. Quando a conexão é feita, os cmdlets do Exchange 2013 são carregados. A partir do Exchange 2013 CU11, o Shell se conectará ao servidor exchange em que a caixa de correio do usuário está registrada. Se o usuário conectado não tiver uma caixa de correio, o Shell se conectará ao servidor em que a caixa de correio de arbitragem SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} está localizada. O servidor de destino pode ser qualquer versão com suporte do Exchange. Isso significa que, se a caixa de correio do usuário conectado (ou a caixa de correio de arbitragem se o usuário não tiver caixa de correio) estiver localizada em um servidor do Exchange 2010, o Shell se conectará a esse servidor e carregará cmdlets do Exchange 2010. Isso pode impedir que você execute determinadas tarefas porque os cmdlets do Exchange 2010 não podem gerenciar a configuração ou os servidores do Exchange 2013.

    A partir do Exchange 2013 CU11, esse comportamento é por design. Para garantir que o Shell carregue cmdlets do Exchange 2013, mova a caixa de correio do usuário registrada para o Exchange 2013. Se o usuário conectado não tiver uma caixa de correio, mova a caixa de correio systemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} para um servidor do Exchange 2013.

    Para obter detalhes e informações sobre como mover a caixa de correio de arbitragem, consulte Shell de Gerenciamento do Exchange e Ancoragem de Caixa de Correio no blog do Exchange Team.

Mailbox

  • Servidores de caixa de correio que executam versões diferentes do Exchange podem ser adicionados ao mesmo grupo de disponibilidade de banco de dados O cmdlet Add-DatabaseAvailabilityGroupServer e o centro de administração do Exchange permitem incorretamente que um servidor do Exchange 2013 seja adicionado a um DAG (grupo de disponibilidade de banco de dados baseado no Exchange 2016) e vice-versa. O Exchange oferece suporte à adição de apenas servidores Caixa de Correio executando a mesma versão (Exchange 2013 versus Exchange 2016, por exemplo) a um DAG. Além disso, o centro de administração do Exchange exibe os servidores Exchange 2013 e Exchange 2016 na lista de servidores disponíveis para adicionar a um DAG. Isso pode permitir que um administrador adicione inadvertidamente um servidor executando uma versão incompatível do Exchange a um DAG (por exemplo, adicionando um servidor Exchange 2013 a um DAG baseado em Exchange 2016).

    Não há uma solução alternativa para esse problema no momento. Os administradores devem estar atentos ao adicionar um servidor Caixa de Correio a um DAG. Adicione somente servidores Exchange 2013 a Exchange 2013baseados em DAGs e somente servidores Exchange 2016 a Exchange 2016 baseados em DAGs. Você pode diferenciar cada versão do Exchange observando a coluna Versão na lista de servidores no Centro de Administração do Exchange. A seguir estão as versões do servidor para o Exchange 2013 e o Exchange 2016:

    • Exchange 2013 15.0 (Build xxx.xx)

    • Exchange 2016 15.1 (Build xxx.xx)

  • O tamanho da caixa de correio aumenta ao migrar das versões anteriores do Exchange: quando você move uma caixa de correio de uma versão anterior do Exchange para o Exchange 2013, o tamanho da caixa de correio relatado pode aumentar de 30% para 40%. O espaço usado pelo banco de dados de caixas de correio não aumentou, somente a atribuição de espaço usado por cada caixa de correio. O aumento no tamanho da caixa de correio se deve à inclusão de todas as propriedades de itens no cálculo da cota, o que proporciona um computação mais precisa do espaço ocupado por itens dentro da caixa de correio. Esse aumento pode fazer que alguns usuários excedam suas cotas de tamanho de caixa de correio quando a caixa deles é movida para o Exchange 2013.

    Para evitar que os usuários excedam suas cotas de tamanho de caixa de correio, aumente os valores de cota do banco de dados ou das caixas de correio para acomodar o novo cálculo de cota. Para configurar valores de cota de banco de dados ou caixa de correio, use os parâmetros IssueWarningQuota, ProhibitSendQuota e ProhibitSendReceiveQuota nos cmdlets Set-MailboxDatabase e Set-Mailbox , respectivamente.

  • Os clientes do Outlook 2007 e do Outlook 2010 podem não conseguir baixar o Catálogo de Endereços Offline: se a URL interna do OAB (Catálogo de Endereços Offline) não estiver acessível na Internet, os clientes do Outlook 2007 e do Outlook 2010 poderão não conseguir baixar a OAB.

    Para contornar esse problema em clientes do Outlook 2007 e do Outlook 2010, torne a URL interna do OAB acessível pela Internet. O Outlook 2013 não é afetado pelo problema.

  • Instalar o Exchange 2013 em uma organização do Exchange existente pode fazer com que todos os clientes baixem a OAB: instalar o primeiro servidor do Exchange 2013 em uma organização existente do Exchange 2007 ou exchange 2010 pode fazer com que todos os clientes da organização baixem uma nova cópia da OAB, resultando em problemas de saturação de rede e desempenho do servidor. Esse problema ocorre porque o Exchange 2013 cria um novo OAB padrão na organização que substitui o OAB do Exchange 2007 ou do Exchange 2010. As caixas de correio que não têm um OAB específico atribuído, ou que estão localizadas em um banco de dados de caixa de correios que não tem um OAB específico atribuído, baixarão o novo OAB padrão.

    Para impedir que os clientes baixem uma nova cópia do OAB quando o Exchange 2013 é instalado, atribua um OAB a cada caixa de correio ou ao banco de dados da caixa de correio onde as caixas estão localizadas. Isso precisa ser feito antes de o Exchange 2013 ser instalado na organização.

  • Os usuários podem ser roteados para uma caixa de correio de geração OAB que não é responsável pela OAB solicitada: o Exchange 2013 CU5 e as CUs posteriores mudaram a forma como os OABs estão vinculados às caixas de correio de geração do OAB. Essa alteração possibilita que um usuário seja roteado até uma caixa de correio de geração de OAB que não é responsável pelo OAB que o usuário está solicitando. isso pode acontecer se todas as condições a seguir forem verdadeiras:

    • Você tem mais de uma caixa de correio de geração de OAB em sua organização.

    • Você atualizou os servidores de Caixa de correio que hospedam as caixas de correio de geração de OAB antes de atualizar seus servidores de Acesso para Cliente.

    • Você está atualizando seus servidores do Exchange 2013 de uma versão anterior ao CU5 para uma versão posterior (por exemplo, atualizando do Exchange 2013 CU3 para o Exchange 2013 CU6).

    • Os servidores de Acesso para Cliente estão executando uma versão anterior ao CU5.

    Para resolver esse problema, atualize seus servidores de Acesso ao Cliente para o Exchange 2013 CU6 ou posterior antes de atualizar seus servidores da Caixa de Correio. Isso garantirá que os servidores do Acesso ao Cliente saibam como fazer proxy das solicitações para a caixa de correio de geração OAB responsável pela geração da OAB do usuário.

    Para ler mais sobre as alterações no OAB no Exchange 2013 CU5, consulte Aprimoramentos do OAB na Atualização Cumulativa 5 do Exchange 2013.

Pastas públicas

  • Remetentes não autorizados não podem mais enviar mensagens para pastas públicas habilitadas para email: antes do Exchange 2013 CU6, remetentes não autorizados poderiam enviar mensagens para pastas públicas habilitadas para email. Isso permitiu a possibilidade de remetentes externos enviarem emails para pastas públicas habilitadas para email, independentemente das permissões definidas na pasta pública.

    A partir do Exchange 2013 CU6, se você quiser que remetentes externos enviem emails para pastas públicas habilitadas para email, o usuário Anônimo precisará receber pelo menos a permissão Criar Itens . Se você tiver configurado pastas públicas habilitadas para email e não tiver feito isso, os remetentes externos receberão uma notificação de falha de entrega e as mensagens não serão entregues à pasta pública habilitada para email.

    Você pode usar o Shell ou o Outlook para definir as permissões no usuário Anônimo. Para ler mais sobre como definir permissões no usuário Anônimo, consulte Habilitar email ou desabilitar uma pasta pública.

  • O número máximo de pastas públicas que podem ser migradas para o Exchange 2013 de servidores herdados do Exchange é de 500.000. Para obter mais informações sobre a migração de pasta pública, consulte Usar a migração em lote para migrar pastas públicas para o Exchange 2013 de versões anteriores.

Fluxo de mensagens

  • Os cmdlets TransportAgent em servidores de Acesso ao Cliente exigem Windows PowerShell local: existe um problema com os cmdlets *-TransportAgent que impede que esses cmdlets instalem, desinstalem e gerenciem agentes de transporte em servidores de Acesso ao Cliente usando o Shell de Gerenciamento do Exchange. Para instalar, desinstalar e gerenciar agentes de transporte em servidores de Acesso ao Cliente, você deve carregar manualmente o snap-in do Exchange Windows PowerShell e, em seguida, executar os cmdlets *-TransportAgent. Se você tentar instalar, desinstalar ou gerenciar agentes de transporte usando o Shell de Gerenciamento do Exchange, as suas alterações serão aplicadas ao servidor de Caixa de Correio do Exchange 2013 ao qual estiver conectado.

    Para instalar, desinstalar ou gerenciar agentes de transporte em servidores de Acesso para Cliente, faça o seguinte no servidor de Acesso para Cliente que deseja gerenciar:

    Aviso

    O carregamento do Microsoft.Exchange.Management.PowerShell.SnapIn Windows PowerShell snap-in e a execução de cmdlets que não sejam os cmdlets -TransportAgent não tem suporte e pode resultar em danos irreparáveis à implantação do Exchange.

    Você deve ser um administrador local no servidor de Acesso ao Cliente em que deseja instalar, desinstalar ou gerenciar agentes de transporte. Não oferecemos suporte à modificação de listas de controle de acesso (ACLs) em arquivos, diretórios ou objetos do Active Directory no Exchange.

    Importante

    Execute o procedimento a seguir apenas em servidores de Acesso para Cliente. Você não precisa carregar o snap-in do Exchange Windows PowerShell se quiser gerenciar agentes de transporte em servidores de caixa de correio.

    1. Abra uma nova janela do Windows Power Shell.

    2. Execute o seguinte comando.

      Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

    3. Execute tarefas de gerenciamento de agente de transporte normalmente.

    4. Repita este procedimento em cada servidor de Acesso para Cliente que deseja gerenciar.

Conectividade de cliente

  • Falha na autenticação NTLM para clientes não associados ao domínio: a autenticação entre um cliente, como Windows Live Mail, e o Exchange 2013 pode falhar quando as seguintes condições forem verdadeiras:

    • Então, o método de autenticação que o cliente usa é NTLM.

    • O computador não ingressou no domínio.

    Para contornar esse problema, execute um destes procedimentos:

    • Ingresse o computador em que o cliente está em execução no domínio.

    • Altere o tipo de autenticação que o cliente usa de NTLM para autenticação Básica por TLS.

  • A autenticação GSSAPI falha quando usada com o cmdlet Send-MailMessage: a autenticação GSSAPI (Generic Security Service Application Program Interface) pode falhar quando o cmdlet Send-MailMessage, incluído com instalações padrão do Windows PowerShell, é usado para enviar emails autenticados para o Exchange 2013. Quando isso acontece, uma entrada será exibida no log de eventos Aplicativo no servidor de Acesso para Cliente no Exchange 2013 que recebeu a conexão com as seguintes informações:

    • Fonte: MSExchangeFrontEndTransport

    • ID do evento: 1035

    • Descrição: falha na autenticação de entrada com erro IllegalMessage para o nome> do servidor Frontend < do cliente do conector de recebimento. O mecanismo de autenticação é Gssapi. O endereço IP de origem do cliente que tentou autenticar no Exchange é [<endereço >IP do cliente].

    Para resolver esse problema, você precisa remover o Integrated método de autenticação do conector de recebimento do cliente em seus servidores do Exchange 2013 Client Access. Para remover o Integrated método de autenticação de um conector de recebimento do cliente, execute o seguinte comando em cada servidor do Exchange 2013 Client Access que poderia receber conexões de computadores que executam o cmdlet Send-MailMessage :

    Set-ReceiveConnector "<server name>\Client Frontend <server name>" -AuthMechanism Tls, BasicAuth, BasicAuthRequireTLS

  • O MAPI sobre HTTP pode ter um desempenho ruim ao atualizar para o Exchange 2013 SP1: se você atualizar de uma atualização cumulativa do Exchange 2013 para o Exchange 2013 SP1 e habilitar o MAPI por HTTP, os clientes que se conectam a um servidor SP1 do Exchange 2013 usando o protocolo podem ter um desempenho ruim. Isso acontece porque as configurações necessárias não são definidas durante uma atualização cumulativa para o Exchange 2013 SP1. Esse problema não ocorrerá se você atualizar para o Exchange 2013 SP1 do Exchange 2013 RTM ou se você instalar um novo servidor do Exchange 2013 SP1 ou mais recente.

    Observação

    Isso só será um problema caso o protocolo MAPI sobre HTTP esteja habilitado em seus servidores de Acesso para Cliente. Ele está desabilitado por padrão. Se MAPI sobre HTTP estiver desabilitado, os clientes usarão o protocolo RPC sobre HTTP.

    Para contornar este problema, proceda da seguinte forma:

    1. Em servidores que executam a função de servidor de Acesso para Cliente, execute os seguintes comandos em um Prompt de Comando do Windows:

      set AppCmdLocation=%windir%\System32\inetsrv
set ExchangeLocation=%ProgramFiles%\Microsoft\Exchange Server\V15

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiFrontEndAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiFrontEndAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiFrontEndAppPool"

    2. Em servidores que executam a função de servidor de Caixa de Correio, execute os seguintes comandos em um Prompt de Comando do Windows:

      set AppCmdLocation=%windir%\System32\inetsrv
set ExchangeLocation=%ProgramFiles%\Microsoft\Exchange Server\V15

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiMailboxAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiMailboxAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiMailboxAppPool"

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiAddressBookAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiAddressBookAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiAddressBookAppPool"

Coexistência do Exchange 2010

  • As solicitações para acessar as caixas de correio do Exchange 2010 podem não funcionar quando proxies por meio de servidores do Exchange 2013 Client Access: em algumas situações, a solicitação de proxy entre os servidores de Acesso ao Cliente do Exchange 2013 e do Exchange 2010 Service Pack 3 (SP3) sem quaisquer roll-ups de atualização instaladas pode não funcionar corretamente e um erro aparece. isso pode acontecer se todas as condições a seguir forem verdadeiras:

    • Um usuário com uma caixa de correio do Exchange 2013 tenta abrir uma caixa de correio do Exchange 2010 usando um dos seguintes métodos:

      • A opção Abrir Outra Caixa de Correio no Outlook Web App -OU-

      • A opção Outro usuário no Centro de administração do Exchange

      • O servidor de Acesso para Cliente ao qual o usuário está conectado está executando o Exchange 2013.

      • O servidor de Acesso para Cliente do Exchange 2010 foi atualizado para o Exchange 2010 SP3 da versão RTM (release to manufacturing) do Exchange 2010 ou um service pack anterior do Exchange 2010.

    Se todas as condições acima forem verdadeiras, o usuário não poderá acessar as opções do Exchange 2010 Outlook Web App do outro usuário e uma página em branco poderá aparecer.

    Para contornar esse problema, instale o Pacote Cumulativo de Atualizações 1 do Exchange 2010 SP3 ou posterior em cada servidor do Exchange 2010.