This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

CPUU Configuration Utility is failing on autodiscover test

We've deployed QMMAD/EX v8.14 in the following environment:
 * Source AD: 2012 R2
 * Source Exchange: Exchange 2013 in a Resource Forest
 * Target AD: 2016 R2
 * Target Exchange: Exchange 2016
 * Outlook 2010 and 2013 clients
 * CPUU v5.8.0

Our console system can successfully resolve autodiscover in the CPUU Config Utility. MAgE Agents can copy source email to the target and mailboxes have been successfully switched.

CPUU, when run on a client, fails. The error in the CPUU log is:
3/15/2019 12:06:32 PM 6584 [Trace] Sending the HTTP request: '<?xml version="1.0" encoding="utf-8"?><Autodiscover xmlns="'">schemas.microsoft.com/.../Autodiscover>'. Headers: 'Content-Type: text/xml'.
3/15/2019 12:06:32 PM 6584 [TraceW] Failed to get Autodiscover response for email 'TEST.USER101@pennstatehealth.psu.edu'. Autodiscover URL: 'autodiscover.pennstatehealth.psu.edu/.../autodiscover.xml'.
WinHTTP result: 0x00002efe, Description: The connection with the server was terminated abnormally
Stack: 00636CC5 00454DB0 005BC189 005A02C7 005B0C02 005B0B1D 005B023B 005D6503 005D8CAA 005F179C 005EEE07 0042A62D 00429EAC 00439A00 00660BD1 BaseThreadInitThunk RtlInitializeExceptionChain RtlInitializeExceptionChain
3/15/2019 12:06:32 PM 6584 [Warning] Cannot get an Autodiscover response for the user 'TEST.USER101@pennstatehealth.psu.edu' from the URL: 'autodiscover.pennstatehealth.psu.edu/.../autodiscover.xml'.
3/15/2019 12:06:32 PM 6584 [Error] Cannot get an Autodiscover response on target. See logged errors to resolve the issue. Profile will not be processed.

When I try to run the CPUU Configuration tool on a workstation where CPUU fails and test autodiscover, I get the following:
"Error: The underlying connection was closed: An unexpected error occurred on a send" only on the target Exchange systems. Source resolves fine.

We can manually create an Outlook 2013 profile and autodiscover resolves and the OL profile is created and can attach to the user's target mailbox.
I'm thinking there may be a firewall or something blocking the config utility's ability to resolve autodiscover at the workstation and therefore, CPUU will always fail.
My question is: What exactly is the CPUU Configuration Utility doing when it tests autodiscover? Like I said, we can manually create an Outlook profile on our test workstation and our console is able to resolve autodiscover without issue.
Is it looking on any other ports than 443? Is it trying various connection methods?
As always, thanks for the assistance.
Eric

Parents
  • Hey Eric, 

    From the console that you're running the config utility on are you able to use EWS Editor and test Autodiscover? 

  • An update: 

    The customer enabled Winhttp to use a stronger protocol and CPUU for both OL2010 and 2013 processed successfully. The Registry entries for this are below:

     reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" /v DefaultSecureProtocols /t REG_DWORD /d 0x00000800 /f

    reg add "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" /v DefaultSecureProtocols /t REG_DWORD /d 0x00000800 /f

    reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v "DisabledByDefault" /t REG_DWORD /d 0x0 /f

    When dealing with severely locked-down environments, we may run into this more often.

Reply
  • An update: 

    The customer enabled Winhttp to use a stronger protocol and CPUU for both OL2010 and 2013 processed successfully. The Registry entries for this are below:

     reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" /v DefaultSecureProtocols /t REG_DWORD /d 0x00000800 /f

    reg add "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" /v DefaultSecureProtocols /t REG_DWORD /d 0x00000800 /f

    reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v "DisabledByDefault" /t REG_DWORD /d 0x0 /f

    When dealing with severely locked-down environments, we may run into this more often.

Children
No Data