Exchange 2010 - Coexistência e migração do Exchange 2016

1

Eu configurei um ambiente de coexistência com o Exchange 2010 e o Exchange 2016.

No momento, o fluxo de mensagens parece funcionar sem problemas, e eu migrei dois usuários de teste de 2010 para 2016.

O tráfego SMTP e o HTTPS são intermediados por proxy da nova instalação do Exchange 2016 - e funciona bem para os usuários de 2010.

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 o RPC / HTTP em direção ao servidor antigo.

Se eu excluir o perfil antigo e recriá-lo usando a descoberta automática, tudo 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:

Eu 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 então eu fiz! Meu telefone celular e OWA funcionam como planejado, e são apenas meus clientes do Outlook que estão agindo. Aconteceu em dois dos meus computadores conectados à mesma caixa de correio e ao mesmo usuário (computador doméstico e de escritório).

Ao abrir meu cliente do outlook, recebo a mensagem de aviso de certificado com o nome interno do meu antigo servidor (como: Exch2010.domain.local) e o certificado em uso é para o 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 me conectar a partir de uma rede externa. Ele me fez a pergunta se eu queria permitir que o link editasse minhas configurações. Eu cliquei em "permitir" e nada aconteceu. A caixa de correio permaneceu em um estado desconectado e o status da conexão tinha uma conexão que tinha o status "estabelecido". A conexão foi intermediada por proxy através do mail.company.com e para o Exch2010.company.local. Eu reiniciei o outlook e aconteceu a mesma coisa.

Em seguida, movi o cliente da rede externa e o coloquei em nossa rede interna. Agora, isso me dá a mesma mensagem "permitir que este site configure as configurações do servidor [email protected]?" mas com o nome local do novo servidor Exchange em um formato de URL como " link ". Eu permiti e aceitei o aviso de certificado (como ele disse 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 é "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. Eu não tenho experiência suficiente para dizer se isso está correto ou não.

Por alguma razão, parece que os servidores estão anunciando internamente seus nomes locais em vez do "mail.company.com" correto.

Também verifiquei os servidores executando:

Get-ClientAccessServer -Identity SERVER | fl

Todos eles têm o AutoDiscoverServiceInternalUri definido como " link ".

O FQDN para todos eles é definido como seus nomes de host locais (servername.company.local).

Não tenho ideia do que tentar em seguida.

Edite o número três; como resposta a @Sembee: Olá @ Sembee; Obrigado pela sua resposta. Deixei-os 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 completos sem problemas e são feitos desde o início. A reconfiguração do outlook de um usuário faz o outlook funcionar novamente (novos dados da descoberta automática). Todo o tráfego está passando pelo servidor de 2016 por enquanto (afaik) e os proxies são OK para o servidor de 2010. Nenhum deles mencionou nenhum problema. O Outlook não está funcionando depois da migração para 2016 sem recriar o perfil e executar uma nova descoberta automática.

Quarta edição: Quando cheguei para trabalhar hoje, meu próprio laptop (não funcionou ontem / domingo) E o laptop (não funcionou no sábado) eu uso para testar ambos funcionaram bem. Pode 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 sincronizá-lo de alguma forma. Qualquer ponteiro seria muito apreciado.

    
por xstnc 05.03.2016 / 18:26

5 respostas

0

Depois de tentar por horas, com a ajuda de um colega; Conseguimos fazer isso funcionar como pretendido.

Comecei com uma reinstalação do Exchange 2016 nos dois novos servidores e configurei-os do zero. Algumas das coisas que fizemos na segunda vez conseguiram que isso funcionasse.

Começamos com a verificação de todas as informações em:

Get-OutlookAnywhere | fl

Definindo -InternalClientsRequireSsl como false; como decidimos que não é necessário internamente devido ao design da rede e ao fato de que nosso certificado não contém o nome interno do nosso servidor.

Também definimos a autenticação para usar o NTLM para autenticação externa e interna para todos os servidores. Também mudamos a prioridade da autenticação do Windows (colocando o NTLM) em cima para o RPC no IIS. Depois de executar uma redefinição do IIS; tudo parece funcionar como pretendido. Não tenho certeza se perdemos uma reinicialização ou reinicialização do IIS em nossa primeira tentativa, mas pelo menos está funcionando agora!

    
por 09.03.2016 / 12:23
0

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 mudar isso.

Em seguida, todos os servidores no mesmo site do AD devem ter as mesmas informações para o URL interno de Descoberta Automática. Além disso, isso deve apontar para o novo servidor e ser um nome que esteja no certificado SSL confiável. Assim:

get-clientaccessserver | set-clientaccessserver -AutodiscoverServiceInternalURI https://mail.example.com/Autodiscover/Autodiscover.xml

Quando você tiver feito 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 do email 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 em Qualquer Lugar. Novamente, isso deve ser idêntico em todos os servidores, pois ele pode fazer proxy em todos os lugares. Verifique o URL interno e externo.

Caixas de correio devem redirecionar automaticamente - não fazer isso pode ser uma indicação de replicação de domínio ruim. No entanto, isso 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 aguardar um pouco para que o domínio replique a alteração para que o Outlook a recupere.

    
por 06.03.2016 / 12:22
0

Eu acho que você tem que considerar como duas partes. Primeiro, olhe a configuração do seu MAPI para o Outlook interno de 2010 ou 2013

Verifique se a autenticação do mapi da configuração do servidor deve selecionar a autenticação do windows ntlm e a autenticação do Windows negocia.

De acordo com documentos da Microsoft, alguns clientes ainda podem se conectar como Rpc / http e funcionarão

    
por 21.12.2016 / 18:43
0

Tivemos o mesmo problema. Depois que os clientes do outlook de migração não se conectam. encontrou o diretório virtual mapi continua removendo a autenticação. Uma vez que isso é colocado de volta, ele se conecta. Se você mudar as URLs, ele apaga as autenticações.

    
por 11.01.2017 / 21:55
0

Acho que este é um problema conhecido da Microsoft, para mim basta reciclar o MSExchangeAutodicoverAppPool do console do IIS ou usar o seguinte comando

Restart-WebAppPool MSExchangeAutodiscoverAppPool

enquanto aguarda uma atualização, você pode configurar a reciclagem automática deste AppPool no IIS que você pode ler neste link

    
por 02.06.2017 / 19:08