Configurei um ambiente de coexistência com o Exchange 2010 e o Exchange 2016.
No momento, o fluxo de email parece funcionar sem problemas, e migrei dois usuários de teste de 2010 para 2016.
O tráfego SMTP e o HTTPS são proxy da nova instalação do Exchange 2016 - e funcionam bem para os usuários de 2010 anteriores.
Meu problema é que, quando os usuários são migrados, o Outlook 2016 está tendo problemas para se conectar ao novo servidor.
Quando abro o Outlook, ele ainda usa RPC/HTTP no servidor antigo.
Se eu excluir o perfil antigo e recriá-lo usando a descoberta automática, ele funcionará bem.
Em seguida, vejo o tráfego MAPI e ele atinge o novo servidor conforme o esperado.
Isso causaria um problema se eu tivesse que recriar perfis manualmente para todos os usuários em nossa empresa.
Alguém tem alguma indicação?
Editado com mais informações:
Migrei meu próprio usuário e abri meu Outlook. Recebi a mensagem de que minha caixa foi migrada e que precisava reiniciar o Outlook; e assim eu fiz! Meu celular e o OWA funcionam como pretendido, e são apenas meus clientes do Outlook agindo mal. Aconteceu em dois dos meus computadores conectados à mesma caixa de correio e ao mesmo usuário (computador doméstico e do escritório).
Ao abrir meu cliente Outlook, recebo a mensagem de aviso de certificado com o nome interno dos meus servidores antigos (como: Exch2010.domain.local), e o certificado em uso é para nosso FQDN como mail.company.com.
Segunda edição:
Acabei de migrar um usuário de teste de 2010 com o Outlook fechado e tentei conectar de uma rede externa. Ele me perguntou se eu queria permitir que https://mail.company.com/autodiscover/autodiscover.xml editasse minhas configurações. Eu cliquei em "permitir" e nada aconteceu. A caixa de correio permaneceu em estado desconectado e o status de conexão tinha uma conexão que tinha o status "estabelecido". A conexão foi feita por proxy através de mail.company.com e para Exch2010.company.local. Reiniciei o Outlook e aconteceu a mesma coisa.
Em seguida, movi o cliente da rede externa e coloquei-o em nossa rede interna. Agora ele me dá a mesma mensagem "permitir que este site defina as configurações do servidor [email protected]?" mas com o nome local do NOVO servidor Exchange em um formato de URL como " https://exch2016.company.local/autodiscover/autodiscover.xml ". Eu permiti e aceitei o aviso de certificado (pois dizia que estava usando o nome local novamente - exch216.company.local; que não corresponde ao certificado SSL).
O Outlook ainda não está operacional e está em um estado "desconectado". Minha própria caixa de correio está "estabelecida", mas não é atualizada.
Por curiosidade, verifiquei os servidores executando:
Get-AutodiscoverVirtualDirectory | fl
InternalURL e ExternalURL para todos os três estão em branco. Não tenho experiência suficiente para dizer se isso é correto ou não.
Por algum motivo, parece que os servidores estão anunciando internamente seus nomes locais em vez do correto "mail.company.com".
Também verifiquei os servidores executando:
Get-ClientAccessServer -Identity SERVER | fl
Todos eles têm o AutoDiscoverServiceInternalUri definido como " https://mail.company.com/autodiscover/autodiscover.xml ".
O FQDN para todos eles é definido como seus nomes de host locais (servername.company.local).
Não tenho ideia do que tentar a seguir..
Edite o número três; como resposta a @Sembee: Olá @Sembee; Obrigado pela sua resposta. Deixei em branco e não fiz alterações. Eu verifiquei o InternalURI para clientaccessserver em todos os três servidores e eles são idênticos. Os testes de descoberta automática são concluídos sem problemas desde o início. A reconfiguração do Outlook de um usuário faz com que o Outlook funcione novamente (dados atualizados da descoberta automática). Todo o tráfego está passando pelo servidor 2016 por enquanto (afaik) e proxies OK para o servidor 2010. Nenhum mencionou problemas. O Outlook simplesmente não está funcionando depois de migrar para 2016 sem recriar o perfil e executar uma nova descoberta automática.
Quarta edição: Quando vim trabalhar hoje, meu próprio laptop (não funcionou ontem/domingo) E o laptop (não funcionou no sábado) que uso para testar ambos funcionaram bem. Poderia ser algum tipo de sincronização atrasada fazendo isso comigo? No momento, estou configurando outro teste, para ver se ele se comporta da mesma maneira - e se é possível cronometrar de alguma forma. Qualquer dica será muito apreciada.
Vamos começar com a parte fácil. Os diretórios virtuais de Descoberta Automática devem estar em branco. Isso é normal e você não deve mudá-los.
Em seguida, todos os servidores no mesmo site do AD devem ter as mesmas informações para a URL de descoberta automática interna. Além disso, isso deve apontar para o novo servidor e ser um nome que esteja no certificado SSL confiável. Desta forma:
get-clientaccessserver | set-clientaccessserver -AutodiscoverServiceInternalURI https://mail.example.com/Autodiscover/Autodiscover.xmlDepois de fazer isso, execute um teste de Descoberta Automática no Outlook. Mantenha pressionada a tecla CTRL enquanto clica com o botão direito do mouse no ícone na bandeja do sistema. Escolha a configuração automática de e-mail de teste. Desmarque a segunda e terceira opções. Execute os testes - veja o que está sendo retornado ao cliente.
Em seguida, verifique a configuração do Outlook Anywhere. Novamente, isso deve ser idêntico em todos os servidores porque pode ser proxy. Verifique a URL interna e externa.
As caixas de correio devem ser redirecionadas automaticamente - não fazer isso pode ser uma indicação de replicação de domínio ruim. No entanto, também depende da rapidez com que você tentou usar a caixa de correio depois de movê-la para o novo servidor. Novamente, você precisa esperar um pouco para que o domínio replique a alteração para que o Outlook a pegue.
Depois de tentar por horas, com ajuda de um colega; conseguimos fazer isso funcionar como pretendido.
Comecei com uma reinstalação do Exchange 2016 em ambos os novos servidores e os configurei do zero. Algumas das coisas que fizemos na segunda vez fizeram isso funcionar.
Começamos verificando todas as informações em:
Definindo -InternalClientsRequireSsl como falso; como decidimos que não é necessário internamente devido ao design da rede e ao fato de nosso certificado não conter o nome interno de nosso servidor.
Também definimos a autenticação para usar NTLM para autenticação externa e interna para todos os servidores. Também alteramos a prioridade da autenticação do Windows (colocando NTLM) no topo para RPC no IIS. Depois de executar uma reinicialização do IIS; tudo parece funcionar como pretendido. Não tenho certeza se perdemos uma redefinição ou reinicialização do IIS em nossa primeira tentativa, mas pelo menos está funcionando agora!
Eu acho que você tem que considerar como duas partes. Primeiro, observe sua configuração MAPI para o Outlook interno 2010 ou 2013
Verifique se a autenticação mapi da configuração do servidor deve selecionar ntlm de autenticação do Windows e negociação de autenticação do Windows.
De acordo com os documentos da Microsoft, alguns clientes ainda podem se conectar como Rpc/http e funcionarão
Tivemos o mesmo problema. Após a migração, os clientes do Outlook não se conectam. encontrado o diretório virtual mapi continua removendo a autenticação. Uma vez que é colocado de volta, ele se conecta. Se você alterar os URLs, isso limpará as autenticações.
Acho que esse é um problema conhecido da Microsoft, para mim, simplesmente recicle o
MSExchangeAutodicoverAppPoolconsole do IIS ou use o seguinte comandoenquanto espera por uma atualização, você pode configurar a reciclagem automática disso
AppPoolno IIS, você pode ler neste linkhttps://support.microsoft.com/en-us/help/3097392/outlook-logon-fails-after-mailbox-moves-from-exchange-2010-to-exchange-2013-or-exchange-2016