Jump to content

VoLLe

Newbie
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

0 Neutral

About VoLLe

  • Rank
    Newbie
  1. Hallo zusammen, ich bin momentan mit meinem Kollegen daran, einen 2013er Exchange Server auf einen 2019er zu migrieren. Postfächer etc. wurden bereits migriert. Soweit so gut. Allerdings machen uns gerade noch das Autodiscover und Outlook einen Strich durch die Rechnung. Momentan sind wir in einer (wahrscheinlich kleinen) Sackgasse: Beim Aufruf der Autodiscover erhalten wir im Browser den errorCode 600: <Autodiscover> <Response> <Error Time="01:11:50.7174697" Id="3664927655"> <ErrorCode>600</ErrorCode> <Message>Ungültige Anforderung</Message> <DebugData/> </Error> </Response> </Autodiscover> Benutzer und Passwort sind valide. Zertifikate sind Signed und Trusted, wobei wir hier ja schon über diesen Punkt hinaus sind. Ich vermute, wir sollten ein "reconfigure autodiscover" machen. Hättet ihr einen Tipp, in welche Richtung es hier ginge? Da wird's bei mir so langsam etwas dünner im IIS. ;) Da wir alle neugierig sind, hab ich mal das Connectivity Tool https://testconnectivity.microsoft.com ohne Autoermittlung durchlaufen lassen und einen fiesen Fehler bekommen; hier der spannende Teil am Ende: Fehler beim Test der Outlook-Verbindung. errorid="734044ef-11c2-4e30-9ee6-450d49e9d92c" testdescription="Die RPC-über-HTTP-Verbindung mit Server &quot;mail.maindomain.tld&quot; wird getestet." resultdescription="Fehler bei RPC-über-HTTP-Verbindung." // mail.maindomain.tld success // https port at mail.maindomain.tld success // certificate success, warning: <testresult status="SuccessWithWarnings" errorid="734044ef-11c2-4e30-9ee6-450d49e9d92c" contentUrl="" testdescription="Die Gültigkeit des SSL-Zertifikats wird überprüft." resultdescription="Das Zertifikat hat alle Überprüfungsanforderungen bestanden." additionaldetails="" elapsedMilliseconds="1238"> <children> [... some cert testresults with success] <testresult status="Warning" errorid="1339c33a-8f21-427b-a323-4cee1a13f517" contentUrl="" testdescription="Die Zertifikatketten werden auf Kompatibilitätsprobleme mit Windows-Versionen analysiert." resultdescription="Test mit Warnungen bestanden. Erweitern Sie die zusätzlichen Details." additionaldetails="Die Microsoft-Verbindungsuntersuchung kann die Zertifikatkette nur überprüfen, wenn die Funktion zum Aktualisieren von Stammzertifikaten aus Windows Update verwendet wird. Möglicherweise wird Ihr Zertifikat von Windows nur dann als vertrauenswürdig eingestuft, wenn die Funktion zum Aktualisieren von Stammzertifikaten aktiviert ist."> </testresult> </children> </testresult> // iis stuff success <testresult status="Success" errorid="00000000-0000-0000-0000-000000000000" contentUrl="" testdescription="Die IIS-Konfiguration wird im Hinblick auf die Clientzertifikatsauthentifizierung überprüft." resultdescription="Keine Clientzertifikatsauthentifizierung erkannt." additionaldetails="Clientzertifikate für Akzeptieren/Anfordern nicht konfiguriert." elapsedMilliseconds="179"> <children /> </testresult> // auth stuff success <testresult status="Success" errorid="00000000-0000-0000-0000-000000000000" contentUrl="" testdescription="HTTP-Authentifizierungsmethoden für URL https://mail.maindomain.tld/rpc/rpcproxy.dll?mail.maindomain.tld:6002 werden getestet" resultdescription="Die HTTP-Authentifizierungsmethoden sind richtig." additionaldetails="Die Microsoft-Verbindungsuntersuchung hat alle erwarteten und keine unzulässigen Authentifizierungsmethoden gefunden. Gefundene Methoden: Negotiate, NTLM&#xD;&#xA;HTTP-Antwortkopfzeilen:&#xD;&#xA;Content-Type: text/html&#xD;&#xA;Server: Microsoft-IIS/10.0&#xD;&#xA;WWW-Authenticate: Negotiate,NTLM&#xD;&#xA;X-Powered-By: ASP.NET&#xD;&#xA;X-DiagInfo: EX19-MAIL&#xD;&#xA;X-BEServer: EX19-MAIL&#xD;&#xA;Date: Wed, 01 Apr 2020 23:21:36 GMT&#xD;&#xA;Content-Length: 1344&#xD;&#xA;" elapsedMilliseconds="133"> <children /> </testresult> // rpc stuff fail <testresult status="Success" errorid="00000000-0000-0000-0000-000000000000" contentUrl="" testdescription="Es wird versucht, ein Ping-Signal an RPC-Proxy mail.maindomain.tld zu senden." resultdescription="Ping für RPC-Proxy erfolgreich ausgeführt." additionaldetails="" elapsedMilliseconds="216"> <children /> </testresult> <testresult status="Error" errorid="483111d0-4317-45bc-991a-a8ad85afd5be" contentUrl="http://go.microsoft.com/?linkid=9843844" testdescription="Es wird versucht, ein Ping-Signal an den Endpunkt &quot;MAPI-E-Mail-Speicher&quot; mit der Identität &quot;mail.maindomain.tld:6001&quot; zu senden." resultdescription="Fehler beim Versuch, ein PING-Signal an den Endpunkt zu senden." additionaldetails="Der RPC_S_SERVER_UNAVAILABLE-Fehler (0x6ba) wurde vom RPC-Laufzeitprozess ausgelöst.&#xD;&#xA;RPC-Status: 1722 ServerUnavailable&#xD;&#xA;Zeitstempel: 4/1/2020 11:21:34 PM&#xD;&#xA;Generierende Komponente: 14 (WinHttp)&#xD;&#xA;Status: 1722&#xD;&#xA;Ort der Ermittlung: 1398 (HTTP2ClientVirtualConnection__ClientOpenInternal90)&#xD;&#xA;0Flags: &#xD;&#xA;-Parameter:&#xD;&#xA;4&#xD;&#xA;1722&#xD;&#xA;Zeitstempel: 4/1/2020 11:21:34 PM&#xD;&#xA;Generierende Komponente: 13 (RpcHttp)&#xD;&#xA;Status: 1722&#xD;&#xA;Ort der Ermittlung: 1418 (HTTP2WinHttpTransportChannel__DelayedReceive120)&#xD;&#xA;0Flags: &#xD;&#xA;-Parameter:&#xD;&#xA;" elapsedMilliseconds="384"> <children /> </testresult> </children> </testresult> </children> </testresult> Das komplette XML hab ich mal angehangen. :) Testdaten waren (pseudo): >Verbindungstests für Microsoft Office Outlook > Outlook-Verbindung Mail: user@other-domain.tld Domain/User: my-ad\user Servereinstellungen: RPC-Proxyserver: mail.maindomain.tld Exchange-Server: mail.maindomain.tld Prinzipalname für ggs. Auth: msstd:mail.maindomain.tld Auth-Methode für RPC-Proxy: Ntlm Portfreigabe auf mail.maindomain.tld (static ip) ist ausschließlich 443 tcp. Jetzt wird's schwieriger. Uns fehlt es leider noch an Wissen, wie die Services in der Domäne von nun an kommunizieren. Das AD wird ja bspw. auch mit einbezogen. Habt erst einmal vielen Dank, dass ihr bis hierher gelesen habt. Wir freuen uns auf neue Inspiration. Beste Grüße, VoLLe RCATestResult.xml
  2. dann schauen wir da nochmal rein danke dir. Ja das wissen wir ;) P.S.: updates folgen
  3. warum versucht der Exchange dann die mail an Mailstest@domainA zu delegieren und nicht wie gewünscht an DomainB vielen dank habs geändert
  4. Hallo Testperson, wir haben das System nicht aufgesetzt pflegen es jetzt nur weiter, und da es bis gestern noch alles ging haben wir es erstmal so gelassen. Die Mails sind an die domainB addressiert und in Domain A gibt es die nicht zwingend, da unterschiedliche Teilbereiche. in DomainB sind die Benutzer aber auch wirklich vorhanden
  5. Hallo Nobbyaushb hab gerade den Post angepasst intern können die Mails verschickt und empfangen werden. Mfg VoLLe
  6. Hallo zusammen, ich sitze gerade vor einer delikaten Problematik: Ein Exchange 2013 Server ist der Meinung, die beiden Maildomain nicht mehr bedienen zu müssen. Generell sind für den Server domainA und domainB eingerichtet. Die Mails kommen definitiv am Exchange an, da der Mailer-Deamon mit einer "Unzustellbar"-Mail antwortet. Auch die generierte Nachricht sagt aus, dass der Mailserver geantwortet hatte. Nun stocherte ich unter Nachrichtenfluss in Empfangskonnektoren usw. herum und bin durch Tutorials für die Einrichtung der Domains gegangen und konnte nichts falsch konfiguriertes feststellen. Alle nötigen Einstellungen sind auf dem ersten Blick vorhanden. Eins noch: Der Empfänger existiert auf dem Exchange Server (valider AD-User, mit Postfach im Exchange auf domain A und B). Das Problem betrifft auch alle Postfächer für domainB. Vielleicht hättet ihr einen Rat für mich. Ich hab noch die Mail vom Server angehangen. PS: Mails kommen bei Strato an, liegen ungelesen im Postfach, werden von FetchMail abgeholt und an Exchange übergeben (haben wir bereits nachgeprüft; ist auch in den Diagnoseinfos ersichtlich) PSS: untereinander können die Postfächer Mails empfangen und senden. nach draußen gehen die Mails auch. Habt vielen Dank! undelivered-mail.txt
  7. Hallo zusammen, ich übernehme gerade die Administration eines größeren Systems und bräuchte kurz eure Hilfe. Folgendes Umfeld: - Office 365 Business (-> aktuelles Office auf PC) - lokaler Exchange Server (mit Strato vorn dran) - neuer (bereits eingerichteter) Win10 Pro PC (nicht selbst eingerichtet, wahrscheinlich bereits im Setup als Organisation), jetzt definitiv in der Domain - Anmeldung über eigenen AD-Server im Netzwerk (nicht Azure) - erstmals an diesem PC angemeldeter AD-Nutzer Normalerweise öffnet man erstmals Outlook, bekommt durch das AD die Email-Adresse voreingetragen (Check!), wählt Exchange aus (Check!), wartet einen Moment und es erscheint direkt das Mailfach. Und da ist auch schon das Problem: Es kommt das Fenster mit dem Titel "Let's get you signed in" (Anhang) mit dem AD-Nutzer ***@***.local vorausgefüllt. Der funktioniert an dieser Stelle natürlich nicht mehr (MS vs. local domain). Die bisherigen Benutzer funktionieren mit Outlook an dem PC tadellos. Vor Kurzem hatten wir das Problem erstmals an einem anderen PC unter Office 2016, konnten allerdings noch auswählen, dass wir ein lokales Konto verwenden möchten (frei zitiert). Damit war es gut. Jetzt ist diese Option jedoch nicht mehr vorhanden und ich komme an diesen Dialog nicht mehr vorbei. Ich hab mich erst frisch in die Office-Welt über Business und privat eingelesen, kratze also noch an der Oberfläche. Habt bitte Nachsicht. :) Gibt es eine Möglichkeit den lokalen AD-Nutzer mit Office 365 Business zu verheiraten?
  8. Habt vielen Dank! Login-Daten werden beim ehemaligen Admin angefragt. :) Die Dokumentation ist tot - lang lebe die Dokumentation!
  9. Okay die VM hat als Hostname "Connector" XD Erstmal vielen Dank! Jetzt brauch ich nur noch die Login-Daten
  10. Ah Moment, es dämmert etwas: Auf dem Server ist neben der VM für Exchange noch ein Debian ... Kann es sein, dass dort Fetchmail läuft, das die Mails von Strato abholt und in Exchange überträgt? Dort müssten dann die neuen Adressen eingepflegt werden, ja? Muss ich erstmal zusehen, dass ich die Login-Daten dafür bekomme
  11. Windows Firewall auf dem Exchange Server und ein LANCOM 1781VAW (over ISDN). Mit Fetchmail hab ich eine Mail des bisherigen Admins gefunden. Mich wundert es halt nach wie vor, warum alle anderen ihre Mails problemlos erhalten und versenden können.
  12. Mich würde es mal reizen zu wissen, wo der herkommt. In Strato wurde er jedenfalls nicht gesetzt.
  13. nslookup -query=mx abc.def abc.def MX preference = 5, mail exchanger = smtpin.rzone.de definitiv die hauptdomain
  14. Das sehe ich auch so. Die Domain bei Strato hat definitiv keine MX Records. Ich befürchte, dass es ein Sonderfall ist
  15. Es gibt keinen MX ... Mails können aber von allen anderen empfangen werden
×
×
  • Create New...