Descoberta Automática Interna do Exchange 2010 Migrar para longe do nome DNS .local atual

Question

Temos um Exchange 2010 Server, em execução em nosso domínio do Active Directory, com um nome de host interno de server.example.local .

O servidor está configurado para o Exchange em qualquer lugar, mas atualmente possui um certificado auto-assinado com um nome de server.example.local instalado.

Internamente, os clientes se conectam e funcionam bem, mas externamente, estamos tendo erros de certificado como seria de esperar.

Estou prestes a comprar um Certificado SSL do UCC para instalar no servidor com todas as SANs relevantes no certificado para corrigir isso, mas devido a um problema óbvio ao obter um certificado confiável com .local como um nome alternativo do assunto, Estou procurando configurar clientes na rede interna para que eles não usem nenhuma referência ao .local hostname.

Configurei nosso nome DNS externo para o servidor como exchange.example.com e criei um CNAME para autodiscover.example.com , o que também (corretamente) aponta para exchange.example.com . Eu também configurei registros DNS internos para esses dois nomes de host que apontam para a interface interna do mesmo servidor. Eu não antecipo nenhum problema aqui.

Agora estou tentando reconfigurar o Auto Discover internamente, para que o Outlook tente se conectar a exchange.example.com . Eu segui as etapas em KB940726 para me preparar para isso, e isso pareceu funcionar bem. Nenhum erro foi gerado e consegui verificar o nome do CAS no AD usando a edição ADSI.

Acabei de testar isso com uma conta de usuário de teste recém-criada, com uma nova caixa de correio do Exchange, e o Outlook 2007 se conecta bem à rede interna, mas, olhando mais fundo no perfil do Exchange, o Outlook ainda está resolvendo o nome do servidor server.example.local .

Poderia ser o certificado autoassinado, que está fazendo com que o Outlook exiba o nome do servidor como server.example.local , ou ainda há algo errado com minha configuração interna de descoberta automática?

Editar

Eu provei que não é o certificado responsável pelo outlook que retorna server.example.local , instalando outro certificado auto-certificado com o nome test.example.com . Ao criar um novo perfil do outlook, recebo o erro de incompatibilidade que estou expondo, mas depois de aceitar o certificado e concluir a configuração do perfil do Outlook, ele ainda mostra server.example.local como o nome do servidor. Isso significa que, se eu comprasse o certificado UCC agora, esse cliente externo funcionaria bem, mas os clientes internos mostrariam uma incompatibilidade de nomes de certificado.

Alguma idéia de onde começar a diagnosticar isso?

    

Answer 1

Acredito que consegui corrigir isso usando a edição ADSI.

Apesar de eu ter executado os comandos no artigo da KB que criei na minha pergunta, encontrei duas entradas de descoberta automática usando a edição ADSI.

• CN = exchange.example.com
• CN = servidor

Eu deletei a entrada CN=server e tive que modificar o serviceBindingInformation property do objeto CN=exchange.example.com para refletir o URL externo correto.

Agora, quando eu configuro um novo perfil de troca ou abro o Outlook para um usuário existente, recebo um erro de incompatibilidade de nome de certificado. No entanto, isso é esperado, pois meu certificado ainda é o certificado autoassinado que tem apenas o nome server.example.local . Posso ver claramente agora que os clientes internos estão procurando o nome exchange.example.com no certificado.

Vou pedir o certificado UCC agora, com nomes de SAN corretos de exchange.example.com e autodiscover.example.com , que acredito que agora me deixarão com um sistema em funcionamento.

Atualizar

Eu já pedi e instalei um certificado confiável com o nome de exchange.example.com , além de uma SAN de autodiscover.example.com , e posso relatar que as perspectivas em qualquer lugar estão funcionando bem nos seguintes cenários

• internamente na rede corporativa example.local com PCs conectados ao domínio.
• externamente com laptops conectados ao domínio em roaming
• externamente com dispositivos móveis (iPhones e iPads)
• externamente com PCs não conectados ao domínio.
• O OWA não apresenta mais erros de SSL.