Pop-ups de credenciais depois de mover a caixa de correio de 2010 para 2016

Question

Situação:

• Exchange 2010 e amp; Coexistência de 2016. O Outlook em Qualquer Lugar está habilitado em ambos com o NTLM

• webmail.domain.com é configurado como o namespace do CAS (para todos os diretórios virtuais em 2016)

• autodiscover.domain.local / autodiscover.autodiscover.xml é configurado como o SCP (a descoberta automática externa não é usada)

• Pontos DNS de ambos os URLs acima para o Exchange 2016

Ao mover caixas de correio de 2010 para 2016, acontece o seguinte:

Para um usuário do Outlook 2010:

• O usuário recebe um pop-up dizendo que o administrador fez uma alteração e o Outlook precisa ser reiniciado

• O usuário reinicia o Outlook (e às vezes obtém o mesmo pop-up novamente e reinicia o Outlook novamente)

• Os usuários recebem um pop-up de credenciais. Se você clicar em cancelar, aparecerá outro popup:

"Permitir que este site configure as configurações do servidor [email protected]?"

autodiscover.domain.com/autodiscover/autodiscover.xml

Como você pode ver, o Outlook 2010 está procurando por autodiscover.domain.com e provavelmente porque a pesquisa do SCP falha.

Se eu fizer um teste de configuração automática do Outlook, ele falhará. A pesquisa do SCP continua fornecendo um redirecionamento 302.

Este parece ser o problema descrito aqui:

Eu posso fazer uma reciclagem dessas AppPools e, em seguida, parece funcionar para alguns clientes do Outlook 2010, mas quase todos os outros clientes do Outlook 2010 na empresa (mesmo de pessoas que ainda não foram movidas) fornecerão um pop-up que o administrador fez uma alteração e esse Outlook precisa ser reiniciado.

Em seguida, para os clientes do Outlook 2013, a reciclagem do AppPool não funciona. Eles continuam recebendo o pop-up de credenciais. Eu posso criar um novo perfil para eles e, em seguida, o Outlook se conecta, mas se eu reiniciar o Outlook novamente, há novamente um pop-up para credenciais.

Além disso, a autoconfiguração do Teste de e-mail funciona bem para eles.

Para os usuários do Outlook 2013, tentei adicionar a seguinte chave do Registro "MapiHttpDisabled" e, em seguida, o perfil antigo e novo do Outlook funciona sem nenhum pop-up! No entanto, quando eu verificar o status da conexão, ele ainda mostra HTTP para o protocolo, o que significa para mim que eles ainda estão usando o protocolo MAPI sobre HTTP, certo?

Além disso, quando verifico os logs do IIS, vejo apenas chamadas no protocolo MAPI, mesmo para os usuários em que adicionei a chave do Registro:

2017-06-08 09:27:25 10.132.33.12 POST / mapi / emsmdb /

Por enquanto, estamos adicionando a chave de registro para todos os usuários de 2013, pois ela parece ser uma solução alternativa, mas não parece uma boa solução:

• MapiHttp é o protocolo do futuro, então não quero desativá-lo

• O registro não parece desativá-lo completamente porque os usuários ainda parecem estar conectados via MapiHttp (de acordo com o status da conexão e os logs do IIS) ??? Esta chave faz outra coisa também?

• Não resolve o problema de reiniciar os usuários do AppPools para 2010.

A seguir, coisas que eu já experimentei:

• Verifique as configurações do OAB no banco de dados: elas estão configuradas corretamente

• No IIS, altere os provedores de Autenticação do Windows do diretório virtual Descoberta Automática, EWS e OAB para apenas NTLM (também tentei mover o NTLM para o início e deixar Negociar). Eu tentei isso em ambos os servidores

• Ativei a autenticação no modo kernel no diretório virtual da Descoberta Automática para Autenticação do Windows

• Adicionei o provedor Negociar: Kerberos ao diretório virtual do mapi no Exchange 2016

• Adicionei a URL de descoberta automática e de webmail aos sites confiáveis no Internet Explorer

• Não há servidor proxy ativado

Nada disso parece fazer diferença. Às vezes, alterar essas configurações forneceu pop-ups para usuários que não tiveram problemas.

Alguma outra sugestão?

    

Answer 1

Acho que resolvi agora. O MAPI / HTTP está habilitado para alguns usuários e nenhum pop-up aparece mais.

Como?

Instalei o cliente do Analisador de Conectividade e ele mostrou que o ponto final do Catálogo de endereços MAPI falhou:

 Error from Connectivity Analyzer:

Testing the address book "Check Name" operation for user xxx against server xxx.
An error occurred while attempting to resolve the name.
Additional Details
Additional Details: A protocol layer error occured. HttpStatusCode: 401
FailureLID: 47372
FailureInfo:

###### REQUEST [2016-09-14T05:06:35.2485121Z] ######

POST /mapi/nspi/?mailboxId=1ad81e37-e4a2-44d9-a465-a7565716b59f@xxx HTTP/1.1
Content-Type: application/octet-stream
User-Agent: MapiHttpClient
X-RequestId: 89b62b49-2d57-4ee2-ba4c-d675bc301556:1
X-ClientInfo: 8d6dea85-a922-4fb3-b454-bc89f733b8c1:1
X-RequestType: Bind
X-ClientApplication: MapiHttpClient/15.01.0106.000
Authorization: Negotiate [truncated]
Host: xxx 
Content-Length: 45

--- REQUEST BODY [+0.003] ---
..[BODY SIZE: 45]

--- REQUEST SENT [+0.003] ---

###### RESPONSE [+0.014] ######

HTTP/1.1 401 Unauthorized
request-id: 1d47e4b9-9933-45c5-96bf-2e4d660a9fd3
X-FailureContext: FrontEnd;401;VW5hdXRob3JpemVk;;;;
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate [truncated]
X-Powered-By: ASP.NET
X-FEServer: MELP-EXCH01
Date: Wed, 14 Sep 2016 05:06:35 GMT
Content-Length: 0

--- RESPONSE BODY [+0.014] ---

--- RESPONSE DONE [+0.014] ---

###### EXCEPTION THROWN [+0.014] ######


HTTP Response Headers:
request-id: 1d47e4b9-9933-45c5-96bf-2e4d660a9fd3
X-FailureContext: FrontEnd;401;VW5hdXRob3JpemVk;;;;
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate 

oXgwdqADCgEBom8EbWBrBgkqhkiG9xIBAgIDAH5cMFqgAwIBBaEDAgEepBEYDzIwMTYwOTE0MDUwNjM1WqUEAgIWjKYDAgEpqRUbE0dSSUZGSVRISEFDSy5DT00uQVWqGTAXoAMCAQGhEDAOGwxtZWxwLWV4Y2gwMSQ=,NTLM
X-Powered-By: ASP.NET
X-FEServer: MELP-EXCH01
Date: Wed, 14 Sep 2016 05:06:35 GMT
Content-Length: 0
HttpStatusCode: 401 Unauthorized
Elapsed Milliseconds: 15

Eu tenho tentado muitas correções diferentes e agora não sei qual foi a solução. Estas são as coisas que fiz (tudo no IIS):

• Coloque o NTLM no topo (em vez de Negociar) na Autenticação do Windows em "Exchange Back End \ mapi \ emssmdb" e "Exchange Back End \ mapi \ nspi"

• Removido "Exigir SSL" para "Back End Exchange \ mapi \ nspi"

• Deu à conta do computador do Exchange e acesso total ao SERVIÇO DE REDE em "D: \ Arquivos de Programas \ Microsoft \ Exchange Server \ V15 \ ClientAccess"

• Removido Negocie com os provedores de Autenticação do Windows do diretório suja do MAPI (Primeiro Site Padrão)

• IISReset

Agora, o Analisador de Conectividade se conecta usando o NTLM e não gera mais nenhum erro. Eu não sei porque é assim porque eu acho que as configurações padrão devem funcionar ou pelo menos os clientes devem usar o NTLM somente se eu especificar o NTLM somente através do comando "Set-MapiVirtualdirectory -IISAuthenticationmethods NTLM".

    

Answer 2

Para os problemas acima com o Outlook 2013:

1. Verifique se o método de autenticação do diretório virtual MAPI é NTLM. Você pode verificar isso executando Get-MAPIVirtualDirectory ou alterá-lo por executando o Set-MAPIVirtualDirectory no servidor do Exchange 2016.

2. Com base na minha experiência, se o UPN e PrimarySMTPAddress do usuário não corresponderem, o Outlook 2013/2016 solicitará credenciais ao iniciar a conexão via MAPI \ HTTP. Você pode verificar isso executando GetAmailbox userA | fl UserPrincipalName, PrimarySMTPAddress . Ou altere-o executando Set-Mailbox UserA -UserPrincipalName xxx .

Além disso, o Exchange 2016 suporta apenas MAPI \ HTTP e RPC \ HTTP, e MAPI \ HTTP é o método de conexão padrão. Depois que você desabilitou o MAPI \ HTTP, o Outlook se conectará ao Exchange via RPC \ HTTP, assim você ainda verá o HTTP no status da conexão do Outlook.