Notas de versão do Exchange 2013

Artigo
03/17/2025

Aplica-se a: Exchange Server 2013

Bem-vindo ao Microsoft Exchange Server 2013! Este tópico contém informações importantes que precisa de saber para implementar o Exchange 2013 com êxito. 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 lançamento do Exchange 2013 instalada Depois de o Exchange expandir o esquema do Active Directory e preparar o Active Directory para o Exchange, são atualizadas várias propriedades para mostrar que a preparação está concluída. Uma destas propriedades é msExchangeProductId no CN=<your organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<domain> contentor no contexto de nomenclatura Configuration . Se não forem introduzidas alterações de esquema do Active Directory na versão do Exchange 2013 que está a instalar, esta propriedade não será atualizada ou poderá apresentar um valor inesperado. Isto pode causar confusão se o valor não corresponder à versão do Exchange 2013 que está a ser instalada.

Este comportamento é esperado porque o valor de msExchProductId não reflete a versão do Exchange 2013 que está a ser instalada. Esta propriedade reflete a versão do Exchange 2013 que efetuou as últimas alterações ao esquema do Active Directory. Para evitar confusões, recomendamos que siga os passos na secção Como sabe que isto funcionou? em Preparar o Active Directory e os domínios para verificar se o Seu Active Directory foi atualizado e está pronto para o lançamento do Exchange 2013 que está a instalar.
Configurar pedidos incorretamente .NET Framework 4.0: se tentar instalar o Exchange 2013 sem .NET Framework instalado no computador, a Configuração solicita incorretamente que instale o .NET Framework 4.0 quando, na verdade, .NET Framework 4.5 ou posterior é necessário.

Para resolver este problema, instale o .NET Framework 4.5 ou posterior. Não é necessário instalar o .NET Framework 4.0. Para obter uma lista completa dos pré-requisitos, consulte Pré-requisitos do Exchange 2013.
Os ficheiros de configuração da aplicação Exchange XML são substituídos durante a instalação da atualização cumulativa: todas as definições personalizadas do Exchange ou do Servidor de Informação Internet por servidor que efetuar nos ficheiros de configuração de aplicações XML do Exchange, por exemplo, web.config ficheiros em servidores de Acesso de Cliente ou no ficheiro de EdgeTransport.exe.config em servidores da Caixa de Correio, serão substituídos quando instalar uma Atualização Cumulativa do Exchange ou um 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 com permissões Administração Delegados faz com que a Configuração falhe Quando um utilizador que seja membro apenas do grupo de funções Configuração Delegada tentar instalar o Exchange num servidor pré-aprovisionado, 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, veja Planeamento e implementação.

Shell de Gerenciamento do Exchange

A Shell carrega inesperadamente os cmdlets do Exchange 2007 ou exchange 2010 Anteriormente, abrir a Shell num servidor do Exchange 2013 resultaria na abertura da Shell de uma ligação ao servidor local ou a outro servidor com o Exchange 2013. Quando a ligação é efetuada, os cmdlets do Exchange 2013 são carregados. A partir do Exchange 2013 CU11, a Shell ligar-se-á ao servidor Exchange onde está localizada a caixa de correio do utilizador com sessão iniciada. Se o utilizador com sessão iniciada não tiver uma caixa de correio, a Shell ligar-se-á ao servidor onde está localizada a caixa de correio de arbitragem SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}. O servidor de destino pode ser qualquer versão suportada do Exchange. Isto significa que, se a caixa de correio do utilizador com sessão iniciada (ou a caixa de correio de arbitragem se o utilizador não tiver caixa de correio) estiver localizada num servidor do Exchange 2010, a Shell ligar-se-á a esse servidor e carregará os cmdlets do Exchange 2010. Isto pode impedir que efetue determinadas tarefas porque os cmdlets do Exchange 2010 não conseguem gerir a configuração ou os servidores do Exchange 2013.

A partir do Exchange 2013 CU11, este comportamento é por predefinição. Para se certificar de que a Shell carrega os cmdlets do Exchange 2013, mova a caixa de correio do utilizador com sessão iniciada para o Exchange 2013. Se o utilizador com sessão iniciada não tiver uma caixa de correio, mova a caixa de correio de arbitragem 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 Gestão do Exchange e Âncora de Caixa de Correio no blogue da Equipa do Exchange.

Mailbox

Os servidores de caixas de correio com versões diferentes do Exchange podem ser adicionados ao mesmo grupo de disponibilidade de base 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 grupo de disponibilidade de bases de dados (DAG) 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 de versões anteriores do Exchange: quando move uma caixa de correio de uma versão anterior do Exchange para o Exchange 2013, o tamanho da caixa de correio comunicado pode aumentar 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 quota de base de dados ou caixa de correio, utilize os parâmetros IssueWarningQuota, ProhibitSendQuota e ProhibitSendReceiveQuota nos cmdlets Set-MailboxDatabase e Set-Mailbox , respetivamente.
Os clientes do Outlook 2007 e do Outlook 2010 poderão não conseguir transferir o Livro de Endereços Offline: se o URL interno do Livro de Endereços Offline (OAB) não estiver acessível a partir da Internet, os clientes do Outlook 2007 e do Outlook 2010 poderão não conseguir transferir o 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 numa organização existente do Exchange pode fazer com que todos os clientes transfiram o OAB: instalar o primeiro servidor do Exchange 2013 numa organização existente do Exchange 2007 ou Exchange 2010 pode fazer com que todos os clientes da organização transfiram uma nova cópia do OAB, o que resulta em saturação da rede e problemas de 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 utilizadores podem ser encaminhados para uma caixa de correio de geração OAB que não é responsável pelo OAB pedido: o Exchange 2013 CU5 e as CUs posteriores alteraram a forma como os OABs estão ligados a caixas de correio de geração 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.
- Está a atualizar os servidores do Exchange 2013 a partir de uma versão anterior à CU5 para uma versão posterior (por exemplo, atualizar 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 este problema, certifique-se de que atualiza os servidores de Acesso de Cliente para o Exchange 2013 CU6 ou posterior antes de atualizar os servidores da Caixa de Correio. Isto irá garantir que os servidores de Acesso de Cliente sabem como fazer o proxy dos pedidos para a caixa de correio de geração OAB que é responsável por gerar o OAB do utilizador.

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

Os remetentes não autorizados já não podem enviar mensagens para pastas públicas com capacidade de correio: antes do Exchange 2013 CU6, os remetentes não autorizados podiam enviar mensagens para pastas públicas com capacidade de correio. Isto permitiu que os remetentes externos enviassem correio para pastas públicas com capacidade de correio, independentemente das permissões definidas na pasta pública.

A partir do Exchange 2013 CU6, se quiser que os remetentes externos enviem correio para pastas públicas com capacidade de correio, o utilizador Anónimo tem de ter, pelo menos, a permissão Criar Itens . Se tiver configurado pastas públicas com capacidade de correio e ainda não o tiver feito, os remetentes externos receberão uma notificação de falha de entrega e as mensagens não serão entregues na pasta pública com capacidade de correio.

Pode utilizar a Shell ou o Outlook para definir as permissões no utilizador Anónimo. Para ler mais sobre como definir permissões no utilizador Anónimo, consulte o artigo Ativar correio ou desativar uma pasta pública.
O número máximo de pastas públicas que podem ser migradas para o Exchange 2013 a partir de servidores do Exchange legados é 500 000. Para obter mais informações sobre a migração de pastas públicas, veja Utilizar a migração de lotes para migrar pastas públicas para o Exchange 2013 a partir de versões anteriores.

Fluxo de mensagens

Os cmdlets TransportAgent nos servidores de Acesso de Cliente requerem Windows PowerShell locais: existe um problema com os cmdlets *-TransportAgent que impedem esses cmdlets de instalar, desinstalar e gerir agentes de transporte em servidores de Acesso de Cliente com a Shell de Gestão do Exchange. Para instalar, desinstalar e gerir agentes de transporte em servidores de Acesso de Cliente, tem de 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 cmdlets de snap-in e execução que não os cmdlets -TransportAgent não é suportado e pode resultar em danos irreparáveis na sua implementação do Exchange.

Tem de ser um Administrador local no servidor de Acesso de Cliente onde pretende instalar, desinstalar ou gerir 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. Não precisa de carregar o snap-in do Exchange Windows PowerShell se quiser gerir agentes de transporte em servidores da 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

A autenticação NTLM falha em clientes não associados a um 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 utilizada com o cmdlet Send-MailMessage: a autenticação GSSAPI (Generic Security Service Application Program Interface) pode falhar quando o cmdlet Send-MailMessage, que está incluído nas instalações predefinidas do Windows PowerShell, é utilizado para enviar correio autenticado 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:
- Origem: MSExchangeFrontEndTransport
- ID do Evento: 1035
- Descrição: a autenticação de entrada falhou com o erro IllegalMessage para Receber o nome> do servidor front-end < do cliente do conector. O mecanismo de autenticação é Gssapi. O endereço IP de origem do cliente que tentou autenticar-se no Exchange é [<endereço> IP do cliente].
Para resolver este problema, tem de remover o Integrated método de autenticação do conector de receção de cliente nos servidores de Acesso de Cliente do Exchange 2013. Para remover o Integrated método de autenticação de um conector de receção de cliente, execute o seguinte comando em cada servidor de Acesso de Cliente do Exchange 2013 que possa receber ligações de computadores com o cmdlet Send-MailMessage :
```
Set-ReceiveConnector "<server name>\Client Frontend <server name>" -AuthMechanism Tls, BasicAuth, BasicAuthRequireTLS
```
MAPI através de HTTP pode ter um fraco desempenho ao atualizar para o Exchange 2013 SP1: se atualizar de uma atualização cumulativa do Exchange 2013 para o Exchange 2013 SP1 e ativar a MAPI através de HTTP, os clientes que se ligam a um servidor do Exchange 2013 SP1 através do protocolo poderão ter um fraco desempenho. 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

Os pedidos de acesso a caixas de correio do Exchange 2010 podem não funcionar quando são fornecidos através de servidores de Acesso de Cliente do Exchange 2013: em algumas situações, o pedido de proxy entre os servidores de Acesso de Cliente do Exchange 2013 e Exchange 2010 Service Pack 3 (SP3) sem quaisquer rollups de atualização instalados pode não funcionar corretamente e é apresentado um erro. 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 utilizador não poderá aceder às opções de Outlook Web App do Exchange 2010 do outro utilizador e poderá ser apresentada uma página em branco.

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

Partilhar via