none
MSExchange Autodiscover Error 1 After CU3 Installation RRS feed

  • Question

  • I had just updated Exchange from CU2 to CU3 and have been getting a steady flow of the following error (below).  I have run the remote connectivity analyzer and it shows all good; Everything seems to be working fine, but these errors are piling up about 50-60 per hour.

    Only other things that were updated about same time is .Net4.8, KB4486153, KB4524148 and KB4515843.

    Is there a bug in the update or something I need to modify somehow?  I am grateful for any assistance.

    Paul

    Log Name:      Application
    Source:        MSExchange Autodiscover
    Date:          10/4/2019 5:59:24 AM
    Event ID:      1
    Task Category: Web
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      ExchangeDAGMember1.local
    Description:
    Unhandled Exception "Object reference not set to an instance of an object."
    Stack trace:    at Microsoft.Exchange.AutoDiscoverV2.FlightSettingRepository.GetHostNameFromVdir(ADObjectId serverSiteId, String protocol)
       at Microsoft.Exchange.AutoDiscoverV2.AutoDiscoverV2.ExecuteOnPremEndFlow(AutoDiscoverV2Request request)
       at Microsoft.Exchange.AutoDiscoverV2.AutoDiscoverV2.Execute(AutoDiscoverV2Request request, ITenantRepository tenantRepository)
       at Microsoft.Exchange.AutoDiscoverV2.AutoDiscoverV2HandlerBase.<>c__DisplayClass11_0.<ProcessRequest>b__0()
       at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="MSExchange Autodiscover" />
        <EventID Qualifiers="49152">1</EventID>
        <Level>2</Level>
        <Task>2</Task>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2019-10-04T10:59:24.943433300Z" />
        <EventRecordID>1824089</EventRecordID>
        <Channel>Application</Channel>
        <Computer>
    ExchangeDAGMember1.local</Computer>
        <Security />
      </System>
      <EventData>
        <Data>Object reference not set to an instance of an object.</Data>
        <Data>   at Microsoft.Exchange.AutoDiscoverV2.FlightSettingRepository.GetHostNameFromVdir(ADObjectId serverSiteId, String protocol)
       at Microsoft.Exchange.AutoDiscoverV2.AutoDiscoverV2.ExecuteOnPremEndFlow(AutoDiscoverV2Request request)
       at Microsoft.Exchange.AutoDiscoverV2.AutoDiscoverV2.Execute(AutoDiscoverV2Request request, ITenantRepository tenantRepository)
       at Microsoft.Exchange.AutoDiscoverV2.AutoDiscoverV2HandlerBase.&lt;&gt;c__DisplayClass11_0.&lt;ProcessRequest&gt;b__0()
       at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)</Data>
      </EventData>
    </Event>


    Paul B

    Friday, October 4, 2019 11:08 AM

All replies

  • Hi

    I would open a case with Microsoft. It might be a bug with .NET 4.8 and Exchange 2019, not saying it is or it could be a windows update causing it.


    Hope this helps. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, October 4, 2019 6:11 PM
    Moderator
  • Paul and Edward, Have exactly the same tons of errors since upgrading from CU2 to CU3. Marcel
    Saturday, October 5, 2019 4:57 AM
  • People having upgraded to CU 14 in Exchange 2016 experience the same errors. They believe it to be a bug in the new Autodiscover routine. Would be nice if Microsoft could comment on it and tell us if we can become active somehow or just have to wait for an upgrade of the upgrade from them.
    Saturday, October 5, 2019 10:17 AM
  • People having upgraded to CU 14 in Exchange 2016 experience the same errors. They believe it to be a bug in the new Autodiscover routine. Would be nice if Microsoft could comment on it and tell us if we can become active somehow or just have to wait for an upgrade of the upgrade from them.
    This is happening to me in Exchange 2016 CU 14 on a brand new install.  Can you point me to the discussions people are having about it in 2016 CU14?
    Sunday, October 6, 2019 8:55 PM
  • Hi,

     

    What's the result when you create new Outlook profile with Autodiscover?

     

    You can use the Test E-mail Autoconfiguration in Outlook:

    1.  Locate the Outlook icon in the notification area, hold the CTRL key, right click the icon, and then click Test E-mail Autoconfiguration.

    2.  Enter the user's email address, only choose Use Autodiscover. View the result on the Log tab.


     

    Check the authentication settings of Autodiscover from IIS. IIS Manager > Default Web Site > Autodiscover > Authentication. Here is the default settings in my environment:


     

    Use the following command to check your Autodiscover internal url, and make sure related DNS records are setting correctly:

     

    Get-ClientAccessService|fl name,*uri*

     

    Regards,

    Kelvin Deng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com


    Monday, October 7, 2019 2:25 AM
  • > You can use the Test E-mail Autoconfiguration in Outlook

    Sure, did that before. The result is a strange error message at first: Error CAA2000B. Correlation ID: effe8025-1e06-47d3-84b4-ced5b939bdb9, Timestamp of today, More info at www.microsoft.com/wamerrors, Server message: AADSTS500014: Resource &#39: https://outlook,office368.com/&#39; is disabled. Trace ID26a44870-1b41-4ee6-aa96-a7f494ef6a00 Correlation ID [as above] Timestamp: [still today]

    Then, when pressing "Continue" in the log as usual here URL Autodiscover to https://outlook.office365.com /autodiscover/autodiscover fails with 0x80040413 but works though SCP.

    IIS Autodiscover settings are as in your example. Get-ClientAccessService|fl name,*uri* points to both mail servers.

    These suggestions IMO point in the wrong direction. Best regards, Marcel

    Monday, October 7, 2019 4:29 AM
  • Chuckd29

    > point me to the discussions people are having about it in 2016 CU14?

    https://www.frankysweb.de/neue-updates-fuer-exchange-server-2016-und-exchange-2019-september-2019/

    As you see it is in German. when searching in English for "Object reference not set to an instance of an object" you get millions of results. Non really identical to our problem. But this is probably the reason why Kelvin Deng thinks it is business as usual.

    Monday, October 7, 2019 4:42 AM
  • Thanks for the link.  This is super frustrating.  My Autodiscover in Exchange 2016 actually works fine for the user mailbox that's hosted on 2016, but we're migrating from 2010 and the public folders are still on 2010.  When trying to open those in Outlook it's supposed to do another Autodiscover and point to the 2010 server.  That's the Autodiscover that's causing the crash on the server and the "Object reference not set to an instance of an object" event.

    I think I'm just going to build a new server and put Exchange 2016 CU13 on it and see if if behaves any differently.

    Monday, October 7, 2019 2:01 PM
  • Exchange 2016 CU13 worked fine on both of my MTA's. Have then migrated both to 2019 CU2 and this worked too. Only with 2019 CU3 these Autodiscover problems started. Good luck.
    Monday, October 7, 2019 3:06 PM
  • Hi Kelvin,

    Sorry I was out of pocket last couple days...

    I checked my authentication settings and they are the same as your defaults, so I assume that is not an issue.

    I ran the autodiscover test and it shows office365 failed, but I expect that since we don't use that; And fo rour domain, it said it "found through SCP", then starting, then httpstatus=200, and finally Succeeded (0x00000000), so I assume that is successful.

    Paul


    Paul B

    Monday, October 7, 2019 4:50 PM
  • I have the exact same error after upgrading Exchange 2019 from CU2 to CU3.  We have MS server 2019 OS with 2019 Exchange in a hybrid O365 deployment.  No user complaints about connectivity.  Still irritating to be running Exchange in a "partially broken" state.  Please post if you find a solution.
    Tuesday, October 8, 2019 2:08 PM
  • I have the exact same error after upgrading Exchange 2019 from CU2 to CU3.  We have MS server 2019 OS with 2019 Exchange in a hybrid O365 deployment.  No user complaints about connectivity.  Still irritating to be running Exchange in a "partially broken" state.  Please post if you find a solution.

    Update Exchange 2016 from CU13 to CU14.

    Unhandled Exception "Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt."
    Stack trace:    bei Microsoft.Exchange.AutoDiscoverV2.FlightSettingRepository.GetHostNameFromVdir(ADObjectId serverSiteId, String protocol)
       bei Microsoft.Exchange.AutoDiscoverV2.AutoDiscoverV2.ExecuteOnPremEndFlow(AutoDiscoverV2Request request)
       bei Microsoft.Exchange.AutoDiscoverV2.AutoDiscoverV2.Execute(AutoDiscoverV2Request request, ITenantRepository tenantRepository)
       bei Microsoft.Exchange.AutoDiscoverV2.AutoDiscoverV2HandlerBase.<>c__DisplayClass11_0.<ProcessRequest>b__0()
       bei Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)

    No Problems on Outlook 2010 and 365.

    But Eventlog is exhausted ...

    Wednesday, October 9, 2019 7:04 AM
  • Also not with Outlook 2016 and 2019. Must be an Exchange server 2016 and 2019 error with the latest CU's. In a DAG configuration with an active server (the one with MX records) and a passive one, only the active exhibits these  MSExchange Autodiscover errors. And yes. event log of the active mail server is full.
    Wednesday, October 9, 2019 8:12 AM
  • In ExchangeServer/V15/ClientAccess/Autodiscover/bin there are 2 dll's: Microsoft.Exchange.Autodiscover.dll, size 394 kB and Microsoft.Exchange.AutodiscoverV2.dll, size 63 kB. Does anybody know how to get Exchange to use the non-V2 version to narrow the search down to one of these?
    Wednesday, October 9, 2019 1:10 PM
  • Hi Kelvin,

    Sorry I was out of pocket last couple days...

    I checked my authentication settings and they are the same as your defaults, so I assume that is not an issue.

    I ran the autodiscover test and it shows office365 failed, but I expect that since we don't use that; And fo rour domain, it said it "found through SCP", then starting, then httpstatus=200, and finally Succeeded (0x00000000), so I assume that is successful.

    Paul


    Paul B

    Hi,

     

    What's the result when you create new Outlook profile with Autodiscover?

     

     

    Regards,

    Kelvin Deng



    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com


    Friday, October 11, 2019 7:02 AM
  • Hi Kelvin,

    I setup new test user on computer and opened Outlook, and it ran and setup test user's mailbox just fine.  Ran test and it shows it succeeded as well:

    ...found through SCP

    Autodiscover... starting

    GetLastError=0 httpStatus=401

    GetLastError=0 httpStatus=200

    Autodiscover …. Succeeded (0x00000000)

    Everything seemingly fine, just errors adding up at about 150 per day.

    Thanks

    Paul


    Paul B

    Friday, October 11, 2019 3:30 PM
  • Unsure if this is related, but I notice on my iPhone that after new messages come into our servers, they appear on phone as normal.  But when I delete a message on the phone, it acts as it deleted, but a duplicate of the message populates the screen immediately following deletion; I look at my Outlook 2016 on my wokstation and the message that I deleted still shows up as unread. After I delete it again, then the message disappears from my workstation Outlook.

    So it seems that this error may be related to iPhone syncing since I have never before had this type of behavior.

     For what its worth, I have an on-premises, 2-member DAG on Exchange 2019; Not sure that if that somehow may be where the duplicates are somehow coming from.

    Just thought someone of higher intelligence than myself may be able to use this information.

    Paul


    Paul B

    Monday, October 14, 2019 4:01 PM
  • Same problem here by the way with Exchange 2016 CU14, opened a case with Microsoft who were saying they are not aware of this issue.


    Wednesday, October 16, 2019 7:07 PM
  • Anything new from Microsoft? Same issue for us with CU14.
    Thursday, October 17, 2019 4:08 PM
  • Not yet, just waiting on a reply. Will post an update here once i have one.
    Thursday, October 17, 2019 4:20 PM
  • Getting the same issue, Exchange 2019 CU3. We are in the process of migrating from 2013 to 2019 and I am seeing these errors in the event log. There is no issues being reported, but it is concerning as to what this error is and why is it happening.

    Once I am done migrating and have uninstalled our old Exchange, if the error persists I will also open a case. I just want to first remove as many variables.

    I see that Martin has a case open, please let us know what the outcome is on this error?

    Friday, October 18, 2019 9:37 PM
  • Hi Paul,

    Do all users have the same mobile synchronization issue?

    Does this issue occur every time when you delete emails with mobile?

    If this issue just occurs with several users, please make sure the Outlook app can connect to the Exchange server and sync information successfully. Please make sure you are using the latest version of Outlook for mobile. 

    You can try to remove your account from Outlook for mobile and add back to see if the synchronization issue is solved.

    Regards,

    Lydia Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Friday, October 25, 2019 1:40 AM
    Moderator
  • Yes.

    But: iOS Devices sync normal but slower than with 2016 cu12. Android devices leave deleted messages in the Mailbox sometimes (often).

    We have this since 2016 cu13 using Sophos Mobile.

    we raised an incident at Sophos but now i think this problem is Microsoft related...

    Can we help to solve this problem ?

    Regards,

    Michael

    Friday, October 25, 2019 5:23 AM
  • It's now more than 20 days since Bock_Paul reported the Autodiscover issue this forum is devoted to and we've received no answer to it only fact finding statements. In the meantime our Event Viewers are full of these error 1 and error 4999. What is happening? Does anyone upgrading from CU2 to CU3 in Exchange 2019 or to CU14 in Exchange 2016 NOT experience these errors?
    Saturday, October 26, 2019 4:34 AM
  • Hey Snx1,

    why should anyone NOT having this Problem read this thread ;) ?

    Rossi

    Monday, October 28, 2019 6:07 AM
  • Update on this: Case still open. Please also open cases if you have this behaviour to ensure visibility on MS end - they are currently collecting them and looking into.

    Still doesn't cause an issue for anybody as it seems.

    Thursday, November 7, 2019 5:50 PM
  • We are having the same issue on Exchange 2019 CU3, have logged a ticket
    Friday, November 8, 2019 6:53 AM
  • I have the same error after upgrading from Exchange2016 CU12 to Exchange2016 CU14. Please place here Microsoft support resolution.

    Monday, November 11, 2019 8:39 AM
  • This is a known issue with Exchange 2019 CU4 and Exchange 2016 CU14

    Note: Autodiscover Event 1 doesn’t cause any issues, other filling up the application logs.

    This issue is under investigation by Microsoft Engineering team


    Monday, November 11, 2019 7:44 PM
  • That should not be marked as proposed answer, first there is no Exchange 2019 CU4 so that is a typo.

    The issue being under investigation is not a solution, keep this thread open until we have a fix in place!

    Tuesday, November 12, 2019 1:09 AM
  • We just want more people to pay attention to this reply and know this is a known issue! 

    We won't lock this thread, any updates can be shared here.

    Regards,

    Lydia Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Tuesday, November 12, 2019 1:47 AM
    Moderator
  • Hi,

    Here is a update about this Autodiscover Event 1 issue.

    Please check the configuration of external urls with the following commands:

    Get-WebServicesVirtualDirectory -server <ServerName> | fl name, *url* Get-AutodiscoverVirtualDirectory -server <ServerName> | fl name, *url* Get-ActiveSyncVirtualDirectory -server <ServerName> | fl name, *url*

    If the external URL is blank for any of them, please assign a value to the external URL that corresponds to the public FQDN.

    Regards,

    Lydia Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Thursday, November 14, 2019 5:30 AM
    Moderator
  • Syntax

    Set-AutodiscoverVirtualDirectory

    -ExternalUrl

    This parameter is available or functional only in Exchange Server 2010.

    "

    So this cannot be an issue on Ex16/19

    Correct ?

    Rossi

    Thursday, November 14, 2019 9:23 AM
  • Hi Rossi,

    If we have Exchange 2010 coexists with Exchange 2016, we can check the ExternalUrl for autodiscover virtual directory.

    Regards,

    Lydia Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Friday, November 15, 2019 2:02 AM
    Moderator
  • Yes the ActiveSyncVirtualDirectory is blank. Not sure how this is not expected behavior in most environments.  

    Manually setting these values does not result in the fields changing from blank to these entered entries anyways. 


    Friday, November 15, 2019 6:25 PM
  • Same problem with Exchange 2016 CU14. Is there any news from Microsoft?

    Thanks

    Monday, November 18, 2019 11:03 AM
  • I just got off the phone with Microsoft.  They provided a workaround, which I have not tried yet.  They advised us to add a group policy that adds the following registry entry to client machines:

     HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
     DisableAutodiscoverV2Service to 1

    The technician told me this would be fixed in the next CU.


    Jan

    Monday, November 18, 2019 3:58 PM
  • I just got off the phone with Microsoft.  They provided a workaround, which I have not tried yet.  They advised us to add a group policy that adds the following registry entry to client machines:

     HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
     DisableAutodiscoverV2Service to 1

    The technician told me this would be fixed in the next CU.  


    Jan


    Jan

    Monday, November 18, 2019 4:00 PM
  • In registry the path HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover exists. Obviously they want us to enter a key or word with the string "DisableAutodiscoverV2Service to 1". This key does not exist yet. We need to know what should be: String Value, Binary Value, DWORD (32 or 64), Multi-string value or Expandable String Value. And do we have to do that with every Office version installed or only in Office 16 and what happens with earlier versions (11, 12, 14, 15).

    At least we know now that the culprit is AutodiscoverV2 module which was introduced with the new CU's in 2916 and 2019 and what we suspected month ago. With this "fix" in registry, the old Microsoft.Exchange.Autodiscover.dll, size 394 kB and not Microsoft.Exchange.AutodiscoverV2.dll would be used.

     > this would be fixed in the next CU

    They would then fix their broken AutodiscoverV2. People applying this "fix" in Office 16 would have to disable it when the new Microsoft.Exchange.AutodiscoverV2.dll finally works. Otherwise Office 16 would use the old Autodiscover forever.

    Tuesday, November 19, 2019 6:35 AM
  • Oh, so another 6-8 months based on the release schedule of the next CU we can expect this error to finally be resolved???

    Nice to hear this finally be acknowledged at least.

    Come on Microsoft...you cant tell me there is not a way to prevent AD v2 acknowledgements at the CAS service / server side!

    Lets throw out a client side registry change to our 12,000 users to clear this up. No sweat...

    PS.

    I do not believe that there should be *any* error or critical events generated in Event Viewer that should be considered: 'safe to ignore'.

    Monday, December 2, 2019 6:16 PM
  • Sometimes they release new CU's in December which would be particularly helpful after the September and this time horrible one. But it can last until February. We're at their mercy. If they intend to punish us longer for using MS so will be it.
    Tuesday, December 3, 2019 3:51 AM
  • Hi,

    Please check this official article for more details about the workaround: Autodiscover Event ID 1 after installing Exchange Server 2019 CU3 or Exchange Server 2016 CU14

    Regards,

    Lydia Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Wednesday, December 4, 2019 5:18 AM
    Moderator
  • Dear Lydia Zhou, we are aware of this URL because your posting here is a repetition and you have not answered the questions in the previous and first posting. We want a robust and immediate solution from Microsoft to this problem that exists since early October and not any shady fixes. Since two months this error, introduced by MS, is clogging our Event Viewers. Why should we fix a problem that MS introduced? It is up to them to finally act in a responsible way. Best regards, Marcel

    Wednesday, December 4, 2019 7:03 AM
  • I see this error logged in the event log as well, is this just noise or is this an indication of something being broken?

    I see there is a workaround by settings external URL as per links in this thread.. but I rather not change anything as everything seems to be working, sounds like it will be fixed in a future SP.

    Monday, December 9, 2019 5:07 AM