Início / server / Perguntas / 1160184
Accepted
JBMacer
Asked: 2024-05-30 21:48:19 +0800 CST

Problemas de OWA/ECP/descoberta automática no local do Exchange 2019

  • 772

Eu estive aqui e ali no StackExchange (imagine minha surpresa ao descobrir que eles são o mesmo grupo, apenas diferentes) e usei perguntas e respostas por anos até agora, quando encontrei um obstáculo que estava apenas me atrapalhando. Então, depois de brigar com o site por mais de uma hora, postei isso originalmente no StackExchange, pois tinha visto vários tópicos e conversas sobre problemas do MS Exchange, mas foi apontado que deveria estar aqui e que o StackExchange é apenas para questões de "programação" . Então eu apaguei e movi para cá. Eu ainda digo que se você tiver apenas dúvidas de programação, livre-se de todas as questões não relacionadas a programação nessa parte do site. Eu apenas postei lá porque já tinha visto muitos outros posts, e usei esses posts muitas vezes.

Na verdade, o logotipo próximo à barra de pesquisa na parte superior ainda mostra “StackExchange” e, embora eu ache que a marca do site seja confusa, é por isso que pensei que StackExchange era o lugar certo para ir. Sim, fiquei chateado depois de lutar para postar por mais de uma hora, e sim, houve tríades sobre a experiência; no entanto, talvez adicionar uma notificação "isso pode não ser uma codificação" com uma opção de redirecionar para ServerFault ou meta ou quaisquer outras opções também seja útil. Então, excluí essa pergunta e estou postando-a aqui.

Vamos ao assunto em questão...

Durante o último mês, temos lidado com o acesso ao OWA e ao ECP sendo inconsistentemente responsivo e super, super lento. Em um minuto eles carregam em 1 a 2 segundos no login, no próximo levam 5 minutos para fazer login e outros 2 minutos para abrir o primeiro item de e-mail. E isso vai e volta aparentemente aleatoriamente. Além disso, ao executar comandos no EMS, recebo a mensagem "A operação de E/S foi abortada devido a uma saída de thread ou a uma solicitação de aplicativo. + FullyQualifiedErrorId: JobFailure

Divulgação completa Eu executo um total de (3) implantações diferentes: 2 são de domínio único (1 um ambiente Server 2019 e 1 um Server 2022) e 1 é uma floresta/multidomínio (ambiente All Server 2019). Todos esses ambientes estão sendo executados como máquinas virtuais em ambientes virtuais Proxmox. Estou tendo um problema com as implantações de Exchange local do Server 2022, domínio único, mas não com as outras.

Aqui está a configuração atual do hardware da VM (observação: o site A e o site B estão conectados por meio de uma VPN): Site A (configurado como "Site A" em Sites e serviços AD com sub-rede 10.2.0.0/16)

  • DC01 (Windows Server 2022)
    • Máquina virtual
      • 4 processadores (2 soquetes, 4 núcleos por)
      • Memória de 8 GiB
    • Placa de rede 1 - 10.2.0.11 (intINet)
      • DNS1 = 10.1.0.11
      • DNS2 = 127.0.0.1
  • EXCH01 (Windows Server 2022 com Exchange 2019 CU14)
    • Máquina virtual
      • 16 processadores (2 soquetes, 8 núcleos por)
      • Memória de 164 GiB
    • Nic 1 - 10.2.0.13 (intINet)
      • Rota 10.1.0.0 && 10.2.0.0 até 10.2.0.1
      • DNS1 = 10.1.0.11 (DC02)
      • DNS2 = 10.2.0.11 (DC01)
    • Nic 2 - public_ip_address (extINet)
      • DNS1 = 10.1.0.11 (DC02)
      • DNS2 = 10.2.0.11 (DC01)

Site B (configurado como "Site B" em Sites e Serviços AD com sub-rede 10.1.0.0/16)

  • DC02 (Windows Server 2022)
    • Máquina virtual
      • 4 processadores (2 soquetes, 4 núcleos por)
      • Memória de 8 GiB
    • Placa de rede 1 - 10.1.0.11 (intINet)
      • DNS1 = 10.2.0.11
      • DNS2 = 127.0.0.1

Sobre o que tentei até agora ...

A primeira coisa que tentei foi mover toda a instância para um novo servidor. Nenhuma melhoria.

Também verifiquei se o DNS está configurado corretamente (veja acima)

Quando uso o Microsoft Remote Connectivity Analyzer, obtenho os seguintes resultados:

  1. Exchange ActiveSync (especificar manualmente as configurações do servidor) - recebo o seguinte erro: Observação: este teste foi aprovado anteriormente com apenas um problema de SSL de "certificado raiz".

    • Uma sessão do ActiveSync está sendo tentada com o servidor.
      • Tentando enviar o comando OPTIONS para o servidor - PASS
      • Tentativa de FolderSyncCommand na sessão do Exchange ActiveSynce - FAILED
        • Detalhes Adicionais: O Exchange ActiveSync retornou uma resposta HTTP 503 (Serviço Indisponível).

  2. Exchange ActiveSync (configurações do servidor Autodiscover) - recebo o seguinte erro na verificação CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS/Autodiscover/Autodiscover.xml:

    • Tentativa de testar o potencial URL de descoberta automática CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS/Autodiscover/Autodiscover.xml - FAILED (não existe no servidor web)
    • Tentativa de testar o potencial URL de descoberta automática https://autodiscover.example.com:443/Autodiscover/Autodiscover.xml - FAILED (deve passar) Observação: quando eu visito https://autodiscover.example.com/Autodiscover/Autodiscover. xml , às vezes solicitará imediatamente um usuário/senha e às vezes levará de 30 a 45 segundos
      • Tentando resolver o nome do host - PASS
      • Testando a porta TCP 443 no host - PASS
      • Testando o certificado SSL - PASS
      • Tentativa de enviar uma solicitação POST de descoberta automática para possíveis URLs de descoberta automática - FAILED
        • O Microsoft Connectivity Analyzer está tentando recuperar uma resposta de Descoberta Automática XML da URL CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS/Autodiscover/Autodiscover.xml para o usuário [email protected] . O Microsoft Connectivity Analyzer não conseguiu obter uma resposta XML de Descoberta Automática. Detalhes adicionais: Detalhes da exceção: Mensagem: A operação expirou Tipo: System.Net.WebException Rastreamento de pilha: em System.Net.HttpWebRequest.GetResponse() Em Microsoft.M365.RCA.Services.RcaHttpRequest.GetResponse()
    • Tentativa de entrar em contato com o serviço Autodiscover usando o método de redirecionamento HTTP - FAILED (HTTP Redirect não configurado)
    • Tentativa de entrar em contato com o serviço Autodiscover usando o método de redirecionamento DNS SRV - FAILED (Not Configured)

Também executei os seguintes comandos e abaixo da lista está a saída com informações de domínio editadas: Comandos:

Get-OabVirtualDirectory | servidor fl, nome, URL , autenticação Get-WebServicesVirtualDirectory | fl server, Nome, URL , autenticação , MRSProxyEnabled Get-EcpVirtualDirectory | servidor fl, nome, URL , autenticação Get-OwaVirtualDirectory | servidor fl, nome, URL , autenticação Get-ActiveSyncVirtualDirectory | servidor fl, nome, URL , autenticação Get-ClientAccessService | fl Nome, OutlookAnywhereEnabled, AutodiscoverServiceInternalUri Get-ExchangeCertificate | fl FriendlyName, Assunto, CertificateDomains, Serviços, Emissor, não , Status Get-OutlookAnywhere | fl server, Nome, URL , nome do host , autenticação Get-MapiVirtualDirectory | fl server, Nome, URL , autenticação Get-OrganizationConfig | fl mapi Get-ClientAccessArray | fl Get-OutlookProvider Get-ExchangeServer | nome fl, admin , estático*

    Creating a new session for implicit remoting of "Get-OabVirtualDirectory" command...

    ( Get-OabVirtualDirectory | fl server, Name, *URL*, *auth* )
    Server                        : EXCH01
    Name                          : OAB (Default Web Site)
    InternalUrl                   : CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS/OAB
    ExternalUrl                   : CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS/OAB
    BasicAuthentication           : False
    WindowsAuthentication         : True
    OAuthAuthentication           : True
    InternalAuthenticationMethods : {WindowsIntegrated, OAuth}
    ExternalAuthenticationMethods : {WindowsIntegrated, OAuth}

    ( Get-WebServicesVirtualDirectory | fl server, Name, *URL*, *auth*, MRSProxyEnabled )
    Server                        : EXCH01
    Name                          : EWS (Default Web Site)
    InternalNLBBypassUrl          :
    InternalUrl                   : CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS/ews/exchange.asmx
    ExternalUrl                   : CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS/ews/exchange.asmx
    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
    MRSProxyEnabled               : False

    ( Get-EcpVirtualDirectory | fl server, Name, *URL*, *auth* )
    Server                        : EXCH01
    Name                          : ecp (Default Web Site)
    InternalUrl                   : CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS/ecp
    ExternalUrl                   : CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS/ecp
    InternalAuthenticationMethods : {Basic, Fba}
    BasicAuthentication           : True
    WindowsAuthentication         : False
    DigestAuthentication          : False
    FormsAuthentication           : True
    LiveIdAuthentication          : False
    AdfsAuthentication            : False
    OAuthAuthentication           : False
    ExternalAuthenticationMethods : {Fba}

    ( Get-OwaVirtualDirectory | fl server, Name, *URL*, *auth* )
    Starting a command on the remote server failed with the following error message : The I/O operation has been aborted because of either a thread exit or an application request. For more information, see the about_Remote_Troubleshooting Help topic.
        + CategoryInfo          : OperationStopped: (exch01.example.local:String) [],     PSRemotingTransportException
        + FullyQualifiedErrorId : JobFailure
        + PSComputerName        : exch01.example.local

O segmento do bloco "JobFailure" foi repetido 10 vezes.

Consegui remover os "comandos concluídos" e completar lentamente o conjunto. Aqui estão esses resultados:

    ( Get-OwaVirtualDirectory | fl server, Name, *URL*, *auth* )
    Server                        : EXCH01
    Name                          : owa (Default Web Site)
    Url                           : {}
    InternalSPMySiteHostURL       :
    ExternalSPMySiteHostURL       :
    SetPhotoURL                   :
    Exchange2003Url               :
    FailbackUrl                   :
    InternalUrl                   : CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS/owa
    ExternalUrl                   : CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS/owa
    ClientAuthCleanupLevel        : High
    InternalAuthenticationMethods : {Basic, Fba}
    BasicAuthentication           : True
    WindowsAuthentication         : False
    DigestAuthentication          : False
    FormsAuthentication           : True
    LiveIdAuthentication          : False
    AdfsAuthentication            : False
    OAuthAuthentication           : False
    ExternalAuthenticationMethods : {Fba}

    ( Get-ActiveSyncVirtualDirectory | fl server, Name, *URL*, *auth* )
    Server                              : EXCH01
    Name                                : Microsoft-Server-ActiveSync (Default Web Site)
    MobileClientCertificateAuthorityURL :
    InternalUrl                         : CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS/Microsoft-Server-ActiveSync
    ExternalUrl                         : CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS/Microsoft-Server-ActiveSync
    MobileClientCertificateAuthorityURL :
    BasicAuthEnabled                    : True
    WindowsAuthEnabled                  : False
    ClientCertAuth                      : Ignore
    InternalAuthenticationMethods       : {}
    ExternalAuthenticationMethods       : {}

    ( Get-ClientAccessService | fl Name, OutlookAnywhereEnabled, AutodiscoverServiceInternalUri )
    Name                           : EXCH01
    OutlookAnywhereEnabled         : True
    AutoDiscoverServiceInternalUri : https://autodiscover.example.com/Autodiscover/Autodiscover.xml

    ( Get-ExchangeCertificate | fl FriendlyName, Subject, CertificateDomains, Services, Issuer, *not*, Status ))
    FriendlyName       : mail.example.com [Certify] - 5/15/2024 3:08:09 PM to 8/13/2024 3:08:08 PM
    Subject            : CN=mail.example.com
    CertificateDomains : {mail.CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS, attachments.example.CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS, autodiscover.CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS, webmail.CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS}
    Services           : IMAP, POP, IIS, SMTP
    Issuer             : CN=R3, O=Let's Encrypt, C=US
    NotAfter           : 8/13/2024 3:08:08 PM
    NotBefore          : 5/15/2024 3:08:09 PM
    Status             : Valid

    FriendlyName       : Microsoft Exchange Server Auth Certificate
    Subject            : CN=Microsoft Exchange Server Auth Certificate
    CertificateDomains : {}
    Services           : SMTP
    Issuer             : CN=Microsoft Exchange Server Auth Certificate
    NotAfter           : 9/30/2027 5:59:59 PM
    NotBefore          : 10/26/2022 5:59:59 PM
    Status             : Valid

    FriendlyName       : Microsoft Exchange
    Subject            : CN=EXCH01
    CertificateDomains : {EXCH01, EXCH01.CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS}
    Services           : IIS, SMTP
    Issuer             : CN=EXCH01
    NotAfter           : 10/26/2027 5:57:07 PM
    NotBefore          : 10/26/2022 5:57:07 PM
    Status             : Valid

    FriendlyName       : WMSVC-SHA2
    Subject            : CN=WMSvc-SHA2-EXCH01
    CertificateDomains : {WMSvc-SHA2-EXCH01}
    Services           : None
    Issuer             : CN=WMSvc-SHA2-EXCH01
    NotAfter           : 10/23/2032 3:47:25 PM
    NotBefore          : 10/26/2022 3:47:25 PM
    Status             : Valid


    ( Get-OutlookAnywhere | fl server, Name, *URL*, *hostname*, *auth* )
    Server                             : EXCH01
    Name                               : Rpc (Default Web Site)
    XropUrl                            :
    ExternalHostname                   : CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS
    InternalHostname                   : CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS
    ExternalClientAuthenticationMethod : Negotiate
    InternalClientAuthenticationMethod : Ntlm
    IISAuthenticationMethods           : {Basic, Ntlm, Negotiate}

    ( Get-MapiVirtualDirectory | fl server, Name, *URL*, *auth* )
    Server                        : EXCH01
    Name                          : mapi (Default Web Site)
    InternalUrl                   : CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS
    ExternalUrl                   : CORRECT-DOMAIN-REMOVED-FOR-LIMITATIONS
    IISAuthenticationMethods      : {Negotiate}
    InternalAuthenticationMethods : {Negotiate}
    ExternalAuthenticationMethods : {Negotiate}

    ( Get-OrganizationConfig | fl *mapi* )
    MapiHttpEnabled     : True

    ( Get-ClientAccessArray | fl )
    NO RESULTS RETURNED

    ( Get-OutlookProvider )
    Name Server CertPrincipalName TTL
    ---- ------ ----------------- ---
    EXCH                          1
    EXPR                          1
    WEB                           1

    Get-ExchangeServer | fl name, *admin*, static* >>
    Name                            : EXCH01
    AdminDisplayVersion             : Version 15.2 (Build 1544.4)
    StaticDomainControllers         : {}
    StaticGlobalCatalogs            : {}
    StaticConfigDomainController    :
    StaticExcludedDomainControllers : {}

Nos meus logs de eventos "Microsoft Exchange com disponibilidade de banco de dados", estou vendo apenas

  • "Erro" para certificados expirados
  • "Erro" para um relatório Watson
  • "Aviso" para o MSExchange ActiveSync de que "A configuração LiveIdBasicAuthModule.ApplicationName no arquivo Web.Config estava faltando. Usando o valor padrão de ." Todo o resto é "Informação"

No meu log de eventos "Eventos Administrativos", estou vendo o acima, além do seguinte:

  • Schannel "Error" - Ocorreu um erro fatal ao criar uma credencial de cliente TLS. O estado de erro interno é 10013. O processamento do cliente SSPI é SYSTEM.
  • "Aviso" Armazenamento de camada intermediária do MSExchange - Cliente do Active Manager já está fazendo consulta para o objeto 'XXX' em outro thread, no entanto, esse thread não compeliu em 100 ms.

No meu log de eventos "Server Roles Web Server (IIS)", estou vendo o seguinte:

  • "Aviso" WAS - Um pool de aplicativos de processamento 'MSExchangeSyncAppPool' sofreu um erro fatal de comunicação com o serviço de ativação do Windows Proess. O ID do processo era 'XXXX'. O campo de dados contém o número do erro.

Só hoje ocorreram 41 desses eventos (de 12h14 CST de 29/05 a 20h44 CST de 29/05)

Algumas pessoas estão sugerindo que este é um problema de DNS; no entanto, ele pode executar ping nos controladores de domínio e, se houvesse um problema de DNS incompatível quando desliguei o DC02, o problema deveria ter sido resolvido; no entanto, isso não aconteceu.

Alguém sugeriu reconstruir todos os diretórios virtuais; no entanto, o sistema estava lento antes de instalar a atualização CU14... a atualização CU14 não reconstruiria/redefiniria os diretórios virtuais?

The other (2) exchange environments I have both allow you to login with 1-2 seconds, MAX. Granted they are running Server 2019 CU10 and CU11 (The client has told me not to update either of them, so not much that I can do.

I am open to any suggestions here.

Thank You in Advance!

Update 202040530 @ 1730Hrs CST

Last night (20240529) I wanted to test the DNS issue theory and I disabled the network on the DC02 VM, and left it off. Nothing changed. In fact, it got worse.

Fast-forward to 10 minutes ago (20240530@1720Hrs CST) I was banging my head on the desk and decided to switch them. I re-enabled the network on DC02 and disabled the network on DC01. Lo and behold, within 3 minutes it is now running like it should. Logging in takes 2-3 seconds on OWA and ECP. Connecting through EMS is fast. This is how it should be.

So, this is not an exchange issue, it is a domain controller issue. I will be running a DCDiag on DC01 when I can re-activate the network, and I will post the results below at that time.

UPDATE - DCDIAG RESULTS: 20240530@2140Hrs CST

As I mentioned earlier, here are the results from running dcdiag. Please note I have changed city names and server names. Please Note: there are a series of DFSREvents in the event log. This were when I had either A.) turned off the network adapter on DC02 or, more recently, turned off the network adapter on DC01 to test and discover that the issue is DC01.

Aside from the errors due to the NIC adapters being disabled, I am not seeing anything that would explain why DC01 is causing all manner of problems for exchange, but DC02 is fine.

See this link for dcdiag results: https://pastebin.com/Ckwe5RdF

UPDATE: 20240601@1722Hrs - Diagnosing Requests

I was asked to do some additional diagnosing steps , but I am not able to paste all the information here.

Please see this link for a full rundown: https://pastebin.com/x6nkBnkM

performance

1 respostas

  1. Best Answer

    Good afternoon everyone, I wanted to provide anyone who might run into this issue later an update with the solution to this particular issue.

    Someone recommended decommissioning DC01 and starting a DC00 on a separate IP address in the same site as DC01/EXCH01. I did this, and it did work for a short time, but within 36 hours the issue had come back up and it was again taking 3-4 minutes to login, and another 1-2 minutes to view the first email address. So, this was not the answer.

    The next thing I did was setup wireshark on DC00, DC01, DC02, and EXCH-01 and watch the traffic as someone attempted to login. During this period it looked like some of the traffic just wasn't making it there, but it was not consistent, and eventually in the logs I would see an ADTopology "information" event that it would loose connection with DC00/DC01.

    This made me look into the persistent routes on the Exchange server. Right now there was a persistent route for 10.2.0.0/16 and 10.1.0.0/16 all going through 10.2.0.1. I looked at some of my other deployments and they all had 10.0.0.0/8 persistent routes. So I modified to match, and of course then the Exchange server was not able to ping anything in the 10.1.0.0/16 network.

    I was a little baffled and decided to look at the router logs and see what was happening to the traffic going to 10.1.0.0/16. As this was a VPN Site-to-Site link using OpenVPN on our pfsense router I started with the OpenVPN logs. Nothing stood out so I started looking at all of the other logs.

    Eventually I wokred my way to the firewall log, and imagine my suprise but there was a lot of traffic being blocked across the LAN network, and when I looked closer it was all from EXCH-01 to DC00 and DC01, specifically port 3268. Why this was being blocked, I do not know; however, it was, and after fixing the previous persistent route issues, restarting the server, and then creating a rule to allow that traffic from EXCH-01 to DC01 everything started to work normally. Login times are down to less than 3 seconds on OWA and ECP both local and using external addresses.

    Now, why did the pfSense router's firewall all the sudden decide that SOME of the traffic to port 3268 should be blocked across the lan interface? I have no idea. That is an issue for another time. However, had I not broken the persistent routing, there is no telling how long it would have taken me to figure this issue out.

    • 0

relate perguntas