Jump to content

Seit Exchange Server2016 CU11 Update kein Clientzugriff mehr möglich.


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar

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)

 

Link zu diesem Kommentar

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.

 

Link zu diesem Kommentar

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.

 

 

 

 

Link zu diesem Kommentar

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 von john23
Link zu diesem Kommentar

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

 

 

 

 

 

Link zu diesem Kommentar

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

Link zu diesem Kommentar
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.

Link zu diesem Kommentar

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!

 

 

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...