none
Exchange 2010 - Autodiscover Probleme RRS feed

  • Frage

  • Hi,

    so wie sich nun unsere Problemstruktur bei meinen Mailservern darstellt ist alles auf Probleme mit Autodiscover zurückzuführen.

    Nun stellt sich mir die Frage ob ich eine einfache Chance habe dies noch mal von Grund auf neu zu konfigurieren quasi einen Reset zu machen oder ob ich hier einen anderen Weg gehen muss.

    Kurze Problembeschreibung - Clients in der Domaine haben kaum Probleme bis auf das manche keinen Zugriff auf den Abwesenheitsassistenten haben.

    Außerhalb der Domaine aber im Netzwerk Geht bei keinem der Abwesenheits Assistent und seit kurzen taucht einen Autodisvocer Meldung auf die sich zu https://mail.your-server.de/autodiscover/autodiscover.xml routen möchte wo mir ein rätsel ist wo dies herkommt also würde ich gerne eben quasi bei Null wieder starten um alle Konfigeinträge richtig zu stellen

    Montag, 22. August 2016 10:56

Antworten

  • Moin,

    die URLs im SCP, OAB, EWS, EAS kannst Du problemlos ändern und die Änderungen sind nach einem Outlook-Neustart sofort wirksam.

    Nur Änderungen des CAS-Array holt sich Outlook nur bei einer Profil-Reparatur.

    Deinen Fehler habe ich früher in Kursen quasi live gezeigt: OOF geht nicht, URLs geändert, Outlook neustart, OOF geht.

    Eventuell dauert es ein paar Minuten, aber kaputtmachen kann man da nichts (ist ja schon kaputt).

    Nachtrag: Nicht-Domänen Clients "raten" eine URL, d.h. hier muss der korrekte Name im DNS eingetragen sein (Stichwort: Split DNS).


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)


    Montag, 22. August 2016 11:03

Alle Antworten

  • Moin,

    die URLs im SCP, OAB, EWS, EAS kannst Du problemlos ändern und die Änderungen sind nach einem Outlook-Neustart sofort wirksam.

    Nur Änderungen des CAS-Array holt sich Outlook nur bei einer Profil-Reparatur.

    Deinen Fehler habe ich früher in Kursen quasi live gezeigt: OOF geht nicht, URLs geändert, Outlook neustart, OOF geht.

    Eventuell dauert es ein paar Minuten, aber kaputtmachen kann man da nichts (ist ja schon kaputt).

    Nachtrag: Nicht-Domänen Clients "raten" eine URL, d.h. hier muss der korrekte Name im DNS eingetragen sein (Stichwort: Split DNS).


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)


    Montag, 22. August 2016 11:03
  • Danke für die Aufbauenden Worte :)

    Ich hab jetzt ein paar dinge gemacht, mit minimalen Veränderungen allerdings etwas das mich verwundert, ich teste mit testconnectivity.microsoft.com alles durch und der Autodiscovertest funktioniert ohne Fehler aber der EWS Test (Microsoft Exchange Web Services Connectivity Tests, <label for="testSelectWizard_ctl09_onPremSelectionList_radioEwsTasks">Synchronization, Notification, Availability, and Automatic Replies) zeigt mir folgenden Fehler:</label>

    Creating a temporary folder to perform synchronization tests.
     
    Failed to create temporary folder for performing tests.

    Additional Details

    Exception details:
    Message: The request failed. Der Remotename konnte nicht aufgelöst werden: 'Mailserver01.meinedomaine.dom'
    Type: Microsoft.Exchange.WebServices.Data.ServiceRequestException
    Stack trace:
    bei Microsoft.Exchange.WebServices.Data.ServiceRequestBase.BuildEwsHttpWebRequest()
    bei Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ValidateAndEmitRequest(IEwsHttpWebRequest& request)
    bei Microsoft.Exchange.WebServices.Data.ExchangeService.InternalBindToFolders(IEnumerable`1 folderIds, PropertySet propertySet, ServiceErrorHandling errorHandling)
    bei Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder[TFolder](FolderId folderId, PropertySet propertySet)
    bei Microsoft.Exchange.Tools.ExRca.Tests.GetOrCreateSyncFolderTest.PerformTestReally()
    Exception details:
    Message: Der Remotename konnte nicht aufgelöst werden: 'Mailserver01.meinedomaine.dom'
    Type: System.Net.WebException
    Stack trace:
    bei System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
    bei System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult)
    bei Microsoft.Exchange.WebServices.Data.ServiceRequestBase.TraceAndEmitRequest(IEwsHttpWebRequest request, Boolean needSignature, Boolean needTrace)
    bei Microsoft.Exchange.WebServices.Data.ServiceRequestBase.BuildEwsHttpWebRequest()
    Elapsed Time: 0 ms.

    und mir ist nicht klar wo her er die Interne Url nimmt statt der Externen habe aber alles geprüft ( soweit mir bekannt/klar/recherchiert ist) und hier sind alle Urls richtig - daher wo kommt dieser falsche eintrag?

     

    Montag, 22. August 2016 13:52
  • Moin,

    zieh doch mal die Autodiscover-Ausgabe mit https://eightwone.com/2010/08/15/standalone-autodiscover-test/, dann wirst Du schon sehen, an welcher Stelle er den falschen FQDN ausgibt. Nach Änderung der URLs sollte man übrigens IISRESET durchführen und die AppPools recyclen. Vielleicht steckt noch irgendwo ein veralteter Eintrag quer...


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Montag, 22. August 2016 15:57