Martin's questions

Tenho uma máquina virtual executando o Windows Server 2019, que é um servidor de terminal com muitas interfaces de rede. Na verdade, é um tronco, que está sendo configurado para muitas interfaces VLAN, levando a tantas interfaces - mas isso não deve importar para minha pergunta. Agora, chegando à parte estranha:

PS C:\Users\XXXX> netstat -n | findstr "192.168.4.80:445"
  TCP    10.0.200.90:49531      192.168.4.80:445       ESTABLISHED
  TCP    10.0.200.90:49532      192.168.4.80:445       ESTABLISHED
  TCP    10.0.200.90:49533      192.168.4.80:445       ESTABLISHED
  TCP    10.0.200.90:49534      192.168.4.80:445       ESTABLISHED
  TCP    192.168.4.90:49528     192.168.4.80:445       ESTABLISHED
  TCP    192.168.4.90:49529     192.168.4.80:445       ESTABLISHED
  TCP    192.168.4.90:49530     192.168.4.80:445       ESTABLISHED
  TCP    192.168.4.90:55959     192.168.4.80:445       ESTABLISHED

Ambas as interfaces em questão aqui são configuradas com uma /24máscara de rede - e a 10.0.200.90/24interface contém o gateway padrão. A tabela de roteamento é bastante grande, pois há muitas interfaces, mas não há rotas conflitantes para a sub-rede 192.168.4.0/24. Aqui estão as partes relevantes:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     10.0.200.250      10.0.200.90    271
       10.0.200.0    255.255.255.0         On-link       10.0.200.90    271
      10.0.200.90  255.255.255.255         On-link       10.0.200.90    271
     10.0.200.255  255.255.255.255         On-link       10.0.200.90    271
      192.168.4.0    255.255.255.0         On-link      192.168.4.90    271
     192.168.4.90  255.255.255.255         On-link      192.168.4.90    271
    192.168.4.255  255.255.255.255         On-link      192.168.4.90    271
===========================================================================

Como é possível que algumas conexões estejam sendo enviadas através do gateway padrão e algumas conexões sigam a rota de interface adequada? Percebi isso no firewall (o gateway padrão), dentro do log do filtro de pacotes, então isso não é apenas um problema de exibição, alguns pacotes realmente estão sendo enviados pelo gateway padrão - E verifiquei através do monitor de recursos, as conexões pertencem a PID 4 (Sistema), que provavelmente são as unidades de rede mapeadas.

Pelo que sei sobre roteamento, a métrica só é levada em consideração se houver duas rotas com a mesma sub-rede - nesse caso, a rota com a métrica mais baixa venceria. Mas a rota do gateway padrão nunca deve vencer uma rota de interface, não importa qual métrica esteja configurada - correto?

Meu primeiro pensamento foi que isso deveria ser um bug dentro do Windows - talvez uma condição de corrida entre o processo que ativa a interface e o processo que mapeia a unidade de rede. Mas isso é pura especulação, eu esperava que alguém pudesse me esclarecer com uma visão mais profunda...

Uma pequena empresa para a qual estou trabalhando tem um Exchange Server 2010 auto-hospedado em execução, e meu trabalho é migrar esse servidor para um servidor Exchange 2016, já que o antigo está sem suporte há algum tempo.

Eu sei que o Exchange 2016 e 2010 podem coexistir e, como não podemos perder nossos e-mails, fiz alguns testes primeiro. Criei um usuário fictício no antigo servidor de troca, criei um trabalho de migração e tentei acessá-lo (mas o objetivo é desligar o servidor antigo após a conclusão da migração).

Mailflow (enviar/receber de/para e-mails externos/internos - tudo funciona!) não é o problema.

Mas não consigo fazer com que os clientes do Outlook (2010) funcionem. Observe que estamos usando o Outlook apenas interno - em uma máquina ingressada no domínio, o acesso externo (atualmente) não é necessário. Sempre que adiciono a conta fictícia ao meu Outlook, tudo funciona como deveria - mas assim que fecho o Outlook e o abro novamente, o Outlook não pode mais acessar o armazenamento de informações. Acessar o e-mail fictício através da URL interna https://ex2016.domain.local/owa/funciona perfeitamente.

Quando eu verifico o status da conexão logo após adicionar a conta de e-mail fictícia, ele mostra essas conexões mapi sobre http (até onde eu sei, esse é o método de acesso padrão desde o exchange 2013). Eu executei o teste de descoberta automática, foi bem sucedido.

Há um aviso de certificado, pois atualmente este é o certificado autoassinado da instalação. Mas também tentei substituir isso por um certificado emitido para um nome de domínio real, mas isso não fez diferença. (Mesmo que eu tenha alterado o certificado e o URL, o Outlook ainda mostrou um aviso de certificado e não tenho ideia do porquê!)

Mas duvido que os problemas do certificado estejam relacionados aos problemas do meu cliente. Durante minha pesquisa na web, encontrei um bug existente nos servidores Exchange 2016, onde a autenticação no diretório virtual mapi não foi habilitada, o que causou a falha dessas conexões de clientes. Verifiquei que (instalei o Exchange 2016 CU21), a microsoft obviamente corrigiu esse bug - na minha instalação, a autenticação já foi habilitada.

Estou realmente perdido agora. Qualquer dica sobre o que pode estar errado é apreciada!

Informações atualizadas

Obrigado pela sua resposta: Em relação à versão do Outlook, verifiquei duas vezes, ela deve ser suportada.

Microsoft Outlook 2010 (14.0.7268.5000) SP2 MSO (14.0.7268.5000)

Com relação ao aviso de certificado: É o primeiro aviso (O certificado de segurança foi emitido por uma empresa na qual você não escolheu confiar). Obrigado pela dica sobre o certificado de instalação, não sabia dessa possibilidade.

O que é realmente estranho, cliquei em instalar, optei por instalá-lo para todo o computador e fechei o Outlook. Depois que reabri o Outlook, o problema acima foi mostrado e, após um minuto, o mesmo aviso de certificado foi exibido novamente, mesmo que eu instalei e cliquei em confiança anteriormente. Repeti o passo, desta vez para o usuário local, e após uma segunda reinicialização, tudo começou a funcionar!

Por que tive que instalar o certificado duas vezes? O Outlook se conecta apenas ao site padrão ( ex2016.domain.local:443) e não ao backend do Exchange ( ex2016.domain.local:444) correto ?

Aqui está o resultado do script powershell (removi todas as referências ao antigo servidor de troca)

Transcript started, output file is C:\log.txt
 C:\Windows\system32>
 
 
PS>Get-OabVirtualDirectory | fl Identity, server, *Auth*, InternalURL, ExternalURL

Identity                      : EX2016\OAB (Default Web Site)
Server                        : EX2016
BasicAuthentication           : False
WindowsAuthentication         : True
OAuthAuthentication           : True
InternalAuthenticationMethods : {WindowsIntegrated, OAuth}
ExternalAuthenticationMethods : {WindowsIntegrated, OAuth}
InternalUrl                   : https://ex2016.domain.local/OAB
ExternalUrl                   :



 C:\Windows\system32>
PS>Get-WebServicesVirtualDirectory | fl Identity, server, *Auth*, InternalURL, ExternalURL 

Identity                      : EX2016\EWS (Default Web Site)
Server                        : EX2016
CertificateAuthentication     :
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
LiveIdNegotiateAuthentication :
WSSecurityAuthentication      : True
LiveIdBasicAuthentication     : False
BasicAuthentication           : False
DigestAuthentication          : False
WindowsAuthentication         : True
OAuthAuthentication           : True
AdfsAuthentication            : False
InternalUrl                   : https://ex2016.domain.local/EWS/Exchange.asmx
ExternalUrl                   :



 C:\Windows\system32>
PS>Get-OutlookAnywhere | fl Identity, server, *Auth*, InternalHostName, ExternalHostName


Identity                           : EX2016\Rpc (Default Web Site)
Server                             : EX2016
ExternalClientAuthenticationMethod : Negotiate
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods           : {Basic, Ntlm, Negotiate}
InternalHostname                   : ex2016.domain.local
ExternalHostname                   :



 C:\Windows\system32>
PS>Get-OwaVirtualDirectory | fl Identity, server, *Auth*, InternalURL, ExternalURL 

Identity                      : EX2016\owa (Default Web Site)
Server                        : EX2016
ClientAuthCleanupLevel        : High
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : True
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
InternalUrl                   : https://ex2016.domain.local/owa
ExternalUrl                   :



 C:\Windows\system32>
PS>Get-ClientAccessServer | fl Identity, Name, AutodiscoverServiceInternalUri

Identity                       : EX2016
Name                           : EX2016
AutoDiscoverServiceInternalUri : https://ex2016.domain.local/Autodiscover/Autodiscover.xml


 C:\Windows\system32>
PS>Get-EcpVirtualDirectory| fl Identity, server, *Auth*, InternalURL, ExternalURL

Identity                      : EX2016\ecp (Default Web Site)
Server                        : EX2016
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : True
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
InternalUrl                   : https://ex2016.domain.local/ecp
ExternalUrl                   :



 C:\Windows\system32>
PS>Get-ActiveSyncVirtualDirectory | fl Identity, server, *Auth*, InternalURL, ExternalURL


Identity                            : EX2016\Microsoft-Server-ActiveSync (Default Web Site)
Server                              : EX2016
MobileClientCertificateAuthorityURL :
BasicAuthEnabled                    : True
WindowsAuthEnabled                  : False
ClientCertAuth                      : Ignore
InternalAuthenticationMethods       : {}
ExternalAuthenticationMethods       : {}
InternalUrl                         : https://ex2016.domain.local/Microsoft-Server-ActiveSync
ExternalUrl                         :



 C:\Windows\system32>
PS>Get-MapiVirtualDirectory | fl Identity, server, *Auth*, InternalURL, ExternalURL


Identity                      : EX2016\mapi (Default Web Site)
Server                        : EX2016
IISAuthenticationMethods      : {Ntlm, OAuth, Kerberos, Negotiate}
InternalAuthenticationMethods : {Ntlm, OAuth, Kerberos, Negotiate}
ExternalAuthenticationMethods : {Ntlm, OAuth, Kerberos, Negotiate}
InternalUrl                   : https://ex2016.domain.local/mapi
ExternalUrl                   : https://ex2016.domain.local/mapi



 C:\Windows\system32>
PS>Get-PowerShellVirtualDirectory | fl Identity, server, *Auth*, InternalURL, ExternalURL


Identity                      : EX2016\PowerShell (Default Web Site)
Server                        : EX2016
CertificateAuthentication     : True
InternalAuthenticationMethods : {}
ExternalAuthenticationMethods : {}
LiveIdNegotiateAuthentication : False
WSSecurityAuthentication      : False
LiveIdBasicAuthentication     : False
BasicAuthentication           : False
DigestAuthentication          : False
WindowsAuthentication         : False
OAuthAuthentication           : False
AdfsAuthentication            : False
InternalUrl                   : http://ex2016.domain.local/powershell
ExternalUrl                   :



 C:\Windows\system32>
PS>Get-ExchangeCertificate | fl Identity, FriendlyName, Subject, CertificateDomains, Services, Issuer, *not*, Status


Identity           : EX2016.domain.local\xxxx_Cert_1_xxxx
FriendlyName       : Microsoft Exchange Server Auth Certificate
Subject            : CN=Microsoft Exchange Server Auth Certificate
CertificateDomains : {}
Services           : SMTP
Issuer             : CN=Microsoft Exchange Server Auth Certificate
NotAfter           : 10.09.2026 15:12:39
NotBefore          : 06.10.2021 15:12:39
Status             : Valid

Identity           : EX2016.domain.local\xxxx_Cert_2_xxxx
FriendlyName       : Microsoft Exchange
Subject            : CN=EX2016
CertificateDomains : {EX2016, EX2016.domain.local}
Services           : IIS, SMTP
Issuer             : CN=EX2016
NotAfter           : 06.10.2026 15:11:29
NotBefore          : 06.10.2021 15:11:29
Status             : Valid

Identity           : EX2016.domain.local\xxxx_Cert_3_xxxx
FriendlyName       : WMSVC-SHA2
Subject            : CN=WMSvc-SHA2-EX2016
CertificateDomains : {WMSvc-SHA2-EX2016}
Services           : None
Issuer             : CN=WMSvc-SHA2-EX2016
NotAfter           : 04.10.2031 12:32:50
NotBefore          : 06.10.2021 12:32:50
Status             : Valid

Identity           : EX2016.domain.local\xxxx_Cert_4_xxxx
FriendlyName       : real.domain.org (rapidssl rsa ca 2018)
Subject            : CN=real.domain.org
CertificateDomains : {real.domain.org}
Services           : IMAP, POP, SMTP
Issuer             : CN=RapidSSL RSA CA 2018, OU=www.digicert.com, O=DigiCert Inc, C=US
NotAfter           : 05.11.2021 13:00:00
NotBefore          : 07.10.2019 02:00:00
Status             : RevocationCheckFailure



 C:\Windows\system32>
PS>Get-OrganizationConfig | fl MapiHttpEnabled


MapiHttpEnabled : True


 C:\Windows\system32>
PS>Get-CasMailbox -Identity Dummy.User | fl MapiHttpEnabled


MapiHttpEnabled :


 C:\Windows\system32>
PS>Stop-Transcript