NorbertFe 2.045 Geschrieben 22. Dezember 2018 Melden Teilen Geschrieben 22. Dezember 2018 vor 24 Minuten schrieb Ralf2019: Ach du Schande ... (glaub ich zumindest). Glauben ist bekanntlich nicht wissen. Also alles ganz locker, da ist nichts drin. :) Zitieren Link zu diesem Kommentar
Ralf2019 0 Geschrieben 22. Dezember 2018 Autor Melden Teilen Geschrieben 22. Dezember 2018 Gut oder schade, dachte hätte endlich mal einen Fehler/neuen Weg gefunden. Also in meinen MAPI Ordner sieht es so aus: \mapi\ mapi\emsmdb mapi\emsmdb\bin(leer) mapi\emsmdbglobal.asax mapi\emsmdbweb.config mapi\emsmdbweb.config.bak mapi\nspi mapi\nspi\bin(leer) mapi\nspi\global.asax mapi\nspi\web.config mapi\nspiweb.config.bak mapi\web.config (keine BAK) Sieht das gut aus oder fehlen Dateien? Ich werde jetzt mal die web.config mit der .bak vergleichen Zitieren Link zu diesem Kommentar
NorbertFe 2.045 Geschrieben 22. Dezember 2018 Melden Teilen Geschrieben 22. Dezember 2018 Du suchst mit ziemlicher Sicherheit an der falschen Stelle. Zitieren Link zu diesem Kommentar
Ralf2019 0 Geschrieben 22. Dezember 2018 Autor Melden Teilen Geschrieben 22. Dezember 2018 Wo würdest du/ würden Sie denn suchen? Autodiscover, IIS, Zertifikate ? m.E. DNS ok Dienste ok Firewall/Ports ok Clients ok/neuste Version virtuelle Verzeichnisse ok/neu erstellt Net SDK neuste Version keine "komischen" Registry Einstellungen für Outlook Fehler tritt auf neustem Windows 10 auf und vorletzter Windows 10 Version auf lokales Avira Professionell hat bei CU10 nicht blockiert Konfig unter CU10 ok, keine Probleme Fehler: CU11 Setup bricht ab, CU 11 recovery Setup läuft imap wird gefunden, Verbindung zum Exchange Server nicht Verbindungstests schlagen fehl mit Session contains no Elements (Watson Protokoll wird erstellt) Zitieren Link zu diesem Kommentar
Ralf2019 0 Geschrieben 23. Dezember 2018 Autor Melden Teilen Geschrieben 23. Dezember 2018 the issue was in IIS configuration on MAPI virtual directory and EWS VIRT EWS VIRT on defaulter web site the negotiate authentication provider was missing under Windows authentication MAPI VIRT on Exchange Back End was configured with Windows authentication instead of anonymous authentication Ich glaube ich bin jetzt auf einer heißen Spur ... noch funktioniert es nicht aber das war trotz zurücksetzen der virtuellen Verzeichnisse nicht in Ordnung. Zitieren Link zu diesem Kommentar
NorbertFe 2.045 Geschrieben 23. Dezember 2018 Melden Teilen Geschrieben 23. Dezember 2018 Geht den Outlook Anywhere? Dann könnte man zumindest erstmal einen Fallback konfigurieren. Oder ist das nur ne Testumgebung? Zitieren Link zu diesem Kommentar
john23 5 Geschrieben 23. Dezember 2018 Melden Teilen Geschrieben 23. Dezember 2018 vor 23 Stunden schrieb NorbertFe: Was sollte es deiner Meinung nach denn ausgeben? Bzw. Auf was sollte er achten? Suche nach eventuell fehlenden Authentifizierungseinstellungen bzw. vielleicht hat das Update da was zerschoßen. Zitieren Link zu diesem Kommentar
Ralf2019 0 Geschrieben 27. Dezember 2018 Autor Melden Teilen Geschrieben 27. Dezember 2018 Ich hoffe Ihr hattet schöne Weihnachten, leider hat sich das Problem über Weihnachten nicht von selbst gelöst ... meine Outlook 2016 Clients verbinden noch immer nicht mit Exchange 2016 CU11 Da mein System leider keine Testumgebung ist, muss ich es bis 02.1 wieder flott bekommen ... Jetzt bin ich nicht remote verbunden sondern "vor Ort". OWA und ECP (Mailempfang, Versand, öffentliche Ordner etc.) funktioniert. OWA und ECP benutzen formularbasierte Authentifizierung. Vor CU11 Update gingen alle Outlook 2016 Clients via mapioverhttp rein im Client-Logfile (vor CU11) steht "negotiate, NTLM und anonymous" Kann man einen RPC Fallback implementieren? Es handelt sich um eine "0/8/15" Installation. Mapi Verzeichnisse (und alle anderen) wurden mehrfach über ECP zurückgesetzt (leider ohne Erfolg). Muss ich beim zurücksetzen des Mapi Verzeichnisses via Exchange Shell außer den Auth Einstellungen weitere Parameter mitgeben? Ich vermute sehr stark, dass es mit den Auth Einstellungen in den/im IIS zusammenhängt. Wie müssen denn virtuelles EWS Verzeichnis und Mapi Verzeichnis im Standardfall eingerichtet sein? Habe beim EWS Backend auch den Ordner "bin" wo ich ein"Auth" setzen kann, bei Mapi im Backend die Ordner emsmdb und nspi ich habe die Auth Einstellungen dort überall einheitlich gewählt. Komisch kommt mir auch vor, das bei mir Mapi im IIS Backend keine Verknüpfung ist sondern ein "normaler Ordner". kann ich das irgendwie ändern (Siehe Screenshot am Anfang dieses Themas). Die IIS hab ich nach jeder Änderung neu gestartet, den Server komplett vielleicht 1-3 mal während meinen Änderungen. Gibt es irgendwo Screenshots, wie alle Werte bei einer Standardinstallation eingerichtet sind? Ich bin langsam am verzweifeln, gerne loben wir auch "Amazon-Gutscheine" oder ähliches aus. Zitieren Link zu diesem Kommentar
john23 5 Geschrieben 27. Dezember 2018 Melden Teilen Geschrieben 27. Dezember 2018 (bearbeitet) https://www.msxfaq.de/exchange/e2013/e2016_default_konfiguration.htm get-mapivirtualdirectory | FL - was steht da den bei der authentifizierung drin? Andere Frage: Wie sieht es aus wenn du ein neues Profil machst. Kannst du das? Werden alle Einstellungen automatisch erkannt? Oder musst du was von Hand eingeben? bearbeitet 27. Dezember 2018 von john23 Zitieren Link zu diesem Kommentar
DocData 85 Geschrieben 27. Dezember 2018 Melden Teilen Geschrieben 27. Dezember 2018 Warum nicht platt machen und per Disaster Recovery Setup wiederherstellen? Zitieren Link zu diesem Kommentar
Ralf2019 0 Geschrieben 27. Dezember 2018 Autor Melden Teilen Geschrieben 27. Dezember 2018 Das ist der Zustand nach einem Disaster Recovery Setup ... RunspaceId : 600f033d-3c32-4d70-acdd-b57181bc4640 IISAuthenticationMethods : {Basic, Ntlm, OAuth, Negotiate} MetabasePath : IIS://XYSERVER2018.xymedia.local/W3SVC/1/ROOT/mapi Path : D:\Exchange2016\FrontEnd\HttpProxy\mapi ExtendedProtectionTokenChecking : None ExtendedProtectionFlags : {} ExtendedProtectionSPNList : {} AdminDisplayVersion : Version 15.1 (Build 1591.10) Server : XYSERVER2018 InternalUrl : https://xyserver2018.xymedia.local/mapi InternalAuthenticationMethods : {Basic, Ntlm, OAuth, Negotiate} ExternalUrl : ExternalAuthenticationMethods : {Basic, Ntlm, OAuth, Negotiate} AdminDisplayName : ExchangeVersion : 0.10 (14.0.100.0) Name : mapi (Default Web Site) DistinguishedName : CN=mapi (Default Web Site),CN=HTTP,CN=Protocols,CN=xySERVER2018,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=xy Media GmbH,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=xymedia,DC=local Identity : xySERVER2018\mapi (Default Web Site) Guid : 3133190f-39b2-4a3e-941e-39867fc4951e ObjectCategory : xymedia.local/Configuration/Schema/ms-Exch-Mapi-Virtual-Directory ObjectClass : {top, msExchVirtualDirectory, msExchMapiVirtualDirectory} WhenChanged : 27.12.2018 12:35:51 WhenCreated : 23.12.2018 20:36:12 WhenChangedUTC : 27.12.2018 11:35:51 WhenCreatedUTC : 23.12.2018 19:36:12 OrganizationId : Id : xySERVER2018\mapi (Default Web Site) OriginatingServer : xySERVER2018.xymedia.local IsValid : True ObjectState : Changed OAuth habe ich heute manuell per Shell ergänzt Zitieren Link zu diesem Kommentar
john23 5 Geschrieben 27. Dezember 2018 Melden Teilen Geschrieben 27. Dezember 2018 Du kannst intern über folgende Befehle Outlook anywhere erzwingen - vielleicht geht es damit. Kannst ja auch erst mal mit get-outlookprovider schauen was momentan gesetzt ist. Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect Set-OutlookProvider EXCH -OutlookProviderFlags:ServerExclusiveConnect If for any reason you need to put the configuration back to its default settings, issue the following commands and clients will no longer prefer HTTP on Fast Networks. Set-OutlookProvider EXPR -OutlookProviderFlags:None Set-OutlookProvider EXCH -OutlookProviderFlags:None Zitieren Link zu diesem Kommentar
NorbertFe 2.045 Geschrieben 27. Dezember 2018 Melden Teilen Geschrieben 27. Dezember 2018 vor 31 Minuten schrieb john23: Du kannst intern über folgende Befehle Outlook anywhere erzwingen - vielleicht geht es damit. Das erzwingt nicht Outlook anywhere. Dazu müsste man allen Postfächern mapi/http verbieten oder es in der org deaktivieren. Ersteres wäre sinnvoller, weil man dann weiterhin am Problem arbeiten kann. Zitieren Link zu diesem Kommentar
Ralf2019 0 Geschrieben 27. Dezember 2018 Autor Melden Teilen Geschrieben 27. Dezember 2018 Es geht wieder! Vielen Dank für alle Hilfen und Kommentare, das neue Jahr fängt doch gut an Die Lösung war die folgende: Im IIS Mapi Backend Verzeichnis auf eine Verknüpfung zurückgesetzt (siehe mein erster Screenshot da war irgend etwas falsch.) Dann Exchange recovery setup, dann musste noch via ECP bei EWS Standardauthentifizierung aktiviert werden und bei Mapi Virtual Directory Kerberos (d. h. bei mapi alle Authentifizierungen an). Die beiden Authentifizierungen oben waren allerdings vorher auch schon gesetzt, das alleine kann es "leider" nicht gewesen sein. Die Änderung mit dem Mapi Verzeichnis im IIS haut auch ne ASP.net Fehlermeldung ("kryptisch") ins Ereignisprotokoll. Es funktioniert soweit aber "alles" (was funktionieren muss). Es wird immer noch mapioverhttp verwendet. Statt NTLM jetzt aber negotiate. Ich bin jetzt erst mal auf das CU12 im März gespannt (werd es dann bei Regenwetter im Sommer anwenden ... und vorher alle IIS Einstellungen abfotografieren ... /screenshots machen ... und hoffe dass dies dann erfolgreich durchläuft. Hab jetzt wieder viel gelernt, hätte es aber lieber unter anderen Bedingungen gelernt Einen guten Rutsch ins neue Jahr 2019! Zitieren Link zu diesem Kommentar
tesso 375 Geschrieben 27. Dezember 2018 Melden Teilen Geschrieben 27. Dezember 2018 Mapi Backend anpassen und danach recovery setup? Wie soll das gehen? Zur Recoveryinstallation brauchst du einen Server ohne Exchange. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.