Substituiu recentemente o certificado SSL em nossa caixa do Exchange 2010 por um novo certificado curinga. Serviços atribuídos, reconfigurados todos os URLs para acesso externo e interno para serem idênticos (o certificado anterior era um certificado SAN com nomes de domínio .local e, como eles não estão mais disponíveis, temos que alterar isso), configure o DNS dividido para clientes internos e externos use o mesmo nome DNS para acesso.
Tudo funciona como esperado, com a exceção de clientes do Outlook recebendo um erro de certificado de incompatibilidade ... parece que o servidor está apresentando o FQDN server.domain.local para o cliente e com o SSL sendo * .domain.com não não combina ...
Eu segui todos os guias / artigos que encontrei, garantindo que todos os URLs sejam configurados corretamente e todos apontem para o mesmo nome DNS externo. A Descoberta automática internamente também funciona e passa (não temos a configuração para descobrir automaticamente externamente, mas o Outlook funciona como deveria quando configurado manualmente, isso foi testado)
O que me deixa perplexo com esse problema é que os perfis / contas recém-criados não têm esse problema, por isso parece ser mais um problema de perfil do Outlook do que um problema de servidor. Eu posso abrir o Outlook e usar meu perfil configurado anteriormente e recebo o erro de incompatibilidade de SSL. Se eu criar um novo perfil do Outlook e configurar minha conta dentro dele, não haverá nenhum erro de SSL.
Não tenho certeza se alguém já se deparou com isso antes ou não, mas qualquer conselho / ajuda seria muito apreciado ... enquanto a reconstrução do perfil do Outlook corrige o problema, com 25 a 30 usuários que não são exatamente algo que eu quero tem que fazer .... Não é algo que deveria ter que ser feito .... Agradecemos antecipadamente por qualquer resposta / assistência.
Argila
Editar -
Meu problema não é bem parecido com a pergunta de alerta de segurança do Outlook mencionada ... mas mais ainda Como este - Erros de certificado do Outlook / Exchange depois de configurar clientaccessserver, etc ... propriedades ... este parece ser quase idêntico ao meu problema ... infelizmente não tem resposta
Eu me deparei com o mesmo problema ao fazer a migração para o Exchange 2013 exigindo substituir o certificado SSL no Exchange 2010 e configurar o OA para habilitar o proxy pelo Exchange 2013. A solução para evitar pop-ups certificados foi importar o modelo de GPO do Outlook 2013 e habilitar GPO para Descoberta Automática para ExcludeLastKnownGoodUrl.
O novo recurso do Outlook 2013 para armazenar os últimos URLs válidos e a ordem de conectividade de processamento quando lançado é o culpado:)
Com base em um comentário que você fez acima, gostaria de fornecer uma visão clara do que você precisa validar para que o ambiente funcione corretamente. Eu vou cobrir todos os aspectos, então algumas coisas que você provavelmente já está trabalhando. 1. Certifique-se de ter "RPC sobre HTTP" instalado no servidor Exchange e operando corretamente (os logs de eventos correspondentes podem ser vistos quando o servidor é inicializado, por exemplo.
Já que você substituiu o seu certificado SSL por curinga, você precisaria decidir como vai referenciar o servidor Exchange dentro de sua rede interna, por exemplo, vamos torná-lo mail.domain.com para o fqdn e mail para o nome do netbios.
Execute os seguintes CMD-lets para localizar e definir as informações corretas como na perspectiva de diretórios virtuais:
Painel de controle do Exchange: Get-ecpVirtualDirectory -Server mail | Set-ecpVirtualDirectory -InternalURL link -ExternalURL link
Get-ECPVirtualDirectory -Server mail | Fl InternalURL, ExternalURL
Outlook Web App: Get-OwaVirtualDirectory -Server mail | Set-OwaVirtualDirectory -InternalURL link -ExternalURL link
Get-OWAVirtualDirectory - Correio do servidor | Fl internalUrl, ExternalURL
EWS (Serviços Web do Exchange): Get-WebservicesVirtualDirectory -Server mail | Set-WebservicesVirtualDirectory -InternalURL link -ExternalURL link
Get-WebservicesVirtualDirectory -Servidor de e-mail | Fl internalURL, ExternalURL
Descoberta automática: Set-ClientAccessServer mail -AutodiscoverServiceInternalUri link
Correio Get-ClientAccessServer | Fl AutodiscoverServiceInternalUri
ActiveSync: Get-ActiveSyncVirtualDirectory -Server mail | Set-ActiveSyncVirtualDirectory -InternalURL link -ExternalURL link
Get-ActiveSyncVirtualDirectory - Correio do servidor | Fl InternalURL, ExternalURL
Catálogo de Endereços Offline: Get-OABVirtualDirectory -Server mail | Set-OABVirtualDirectory -InternalUrl link -ExternalURL link
Get-OABVirtualDirectory -Server mail | Fl InternalURL, ExternalURL
OutlookAnywhere: Set-OutlookAnywhere -Identity mail \ Rpc (Site padrão) "-InternalHostname mail.domain.com -ExternalHostName mail.domain.com -InternalClientAuthenticationMethod ntlm -InternalClientsRequireSsl: $ True -ExternalClientAuthenticationMethod Basic -ExternalClientsRequireSsl: $ True
Get-OutlookAnywhere -Identity mail \ rpc (Site padrão) "| fl InternalHostName, InternalClientAuthenticationMethod, InternalClientsRequiressl, ExternalHostName, ExternalClientAuthenticationMethod, ExternalClientsRequiressl
Execute iisreset /restart após o script acima, lembre-se de substituir o correio pelo nome real do netbios do servidor e mail.domain.com pelo fqdn real do seu servidor Exchange.
Em relação ao provedor do Outlook, veja aqui: link
Deixe-me saber se você tem alguma dúvida.
Tivemos o mesmo problema depois de remover nosso domínio local de nossos certificados do Exchange e descemos o mesmo caminho de solução de problemas, Clay.
Descobrimos que o cache do "último bem conhecido" no Outlook 2013 foi o culpado ao desativar esse recurso por meio do registro para alguns PCs afetados.
Então percebemos que a causa raiz era porque deixamos o antigo registro "local" no dns. O Outlook 2013 estava procurando cache para a descoberta automática antiga e, como ela ainda existia, apesar de não corresponder ao certificado, ela nunca procurava o novo endereço.
Eu sei que isso é antigo, mas achei que pode ajudar outra pessoa.
Acabei de ter o mesmo problema que você está descrevendo, até o T.
A resolução era desabilitar o modo em cache nos perfis afetados. Abra o Outlook, feche o Outlook. Reative o modo em cache e o problema desapareceu.
Espero que isso economize tempo para os outros:)
Então eu tive exatamente o mesmo problema depois de instalar um certificado SSL em nosso servidor Exchange local para mail.company.com.
Todos os clientes do Outlook na LAN começaram a receber "O nome no certificado de segurança é inválido ou não corresponde ao nome do site", seguido por "Permitir que este site configure as configurações do servidor usuá[email protected]? link "prompt.
Corri o utilitário DigiCert Exchange, criei um script, verifiquei, recuperei e fiz backup de todas as configurações existentes usando "Get-" e, em seguida, executei o script no Shell de Gerenciamento do Exchange:
Set-ClientAccessServer -Identity "LocalServer" -AutodiscoverServiceInternalUri "https://mail.company.com/Autodiscover/Autodiscover.xml"
Set-OABVirtualDirectory -Identity "LocalServer\OAB (Default Web Site)" -InternalUrl "http://mail.company.com/OAB"
Set-WebServicesVirtualDirectory -Identity "LocalServer\EWS (Default Web Site)" -InternalUrl "https://mail.company.com/EWS/Exchange.asmx"
Set-ActiveSyncVirtualDirectory -Identity "LocalServer\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl "https://mail.company.com/Microsoft-Server-ActiveSync"
Set-OWAVirtualDirectory -Identity "LocalServer\owa (Default Web Site)" -InternalUrl "https://mail.company.com/owa"
Set-ECPVirtualDirectory -Identity "LocalServer\ecp (Default Web Site)" -InternalUrl "https://mail.company.com/ecp"
Isso não resolveu os prompts de aviso nos clientes depois de um ipconfig / flushdns, gpupdate / force e um reinício, então eu verifiquei alguns outros itens:
mail.company.com foi registrado no certificado SSL - ok.
Entrada Alias do servidor DNS local mail.company.com para LocalServer.company.com - ok
Encontrado um servidor DNS local duplicado Host LocalServer.company.com para 192.168.1.11 e para 192.168.1.60 - Excluída a segunda entrada incorreta.
Encontrado o servidor DNS local Alias autodiscover.company.com para LocalServer.company.com - Exclua esta entrada, ipconfig / flushdns e feche e abra o Outlook em clientes e tudo pareceu funcionar!
O que o link da base de dados da Microsoft ea ferramenta DigiCert Exchange iludiram é outra configuração que Descobri subseqüentemente qual provavelmente teria abordado o prompt AutoDiscover corretamente:
Set-AutodiscoverVirtualDirectory -Identity "LocalServer\Autodiscover (Default Web Site)" -InternalUrl "https://mail.company.com/autodiscover/autodiscover.xml"
Set-AutodiscoverVirtualDirectory -Identity "LocalServer\Autodiscover (Default Web Site)" -ExternalUrl "https://mail.company.com/autodiscover/autodiscover.xml"
Ambas as entradas estão em branco no meu servidor Exchange, portanto, testará o preenchimento e o feedback novamente.
EDIT: Então eu coloquei o InternalUrl para mail.company.com/autodiscover/autodiscover.xml, e quando eu verifiquei os clientes do Outlook por CTRL + clique com o botão direito do mouse no ícone da bandeja do Outlook, Testar Configuração Automática de E-mail ... , Teste, Log, role para baixo e encontre a linha Autodiscover para, ele tem o novo endereço lá e tem um status de sucesso!
Eu vi outro artigo onde eles adicionaram o autodiscover.company.com ao certificado SSL como uma solução, o que também resolveria o problema nesse cenário. No entanto, esse é um recurso desperdiçado na minha situação, pois temos certificados SSL limitados .
Tudo funcionando, agora apenas para descobrir conexões de fora e roteamento através do firewall:)
Tags ssl outlook exchange-2010