Exchange 2016 - MAPI over HTTP

[PowerShellAdmin 169]

Ahoi,

ich bin ja derzeit in der Exchange 2016 Bereitstellung (Exchange 2010 und 2016 Mischumgebung)

In Exchange 2016 ist innerhalb der Organisation -Intranet- der Clientzugriff via Outlook ja über Mapi / Http empfohlen.

 

Exchange 2016 VDirectories Konfiguration (2Node DAG):

 

Node 1: Node1.domain.tld => VDirectory Settings Mapi: mail.domain.tld

Node 2: Node2.domain.tld => VDirectory Settings Mapi: mail.domain.tld

Die weiteren VDirectories sind ebenfalls auf mail.domain.tld gesetzt.

 

Im Intranet (Splitdns) ist nun ein A-Record für mail.domain.tld auf den Loadbalancer gesetzt, aber auch Round Robin getestet.

Mapi wurde aktiviert:

Set-OrganizationConfig -MapiHttpEnabled $true

 

Nun wurde ein altes Test-Postfach tesweise auf den Exchange 2010 auf den 2016 verschoben.

Der Aufruf in Outlook funktioniert, der LB tut seinen Dienst.

 

Zertifikatsfehler für mail.domain.tld wird angezeigt => korrekt, das San Zert lasse ich entsprechend noch erweitern.

Zertifikatsfehler für node1.domain.tld bzw node2.domain.tld wird angezeigt=> habe ich hier einen Denkfehler oder ist das ein Resultat des Mischbetriebes?

bearbeitet 22. September 2016 von PowerShellAdmin

[NorbertFe 2.035]

Solange du Exchange 2010 in deiner org hast, solltest du auf Mapi http verzichten.

[PowerShellAdmin 169]

danke habe es deaktiviert und mir erstmal entsprechendes Zertifikat erzeugt.

Nach korrekter MAPI over http Umstellung, benötige ich in diesem Fall aber keine Zertifikate für die FQDN der Hosts wie bei RPC oder?

[NorbertFe 2.035]

Die brauchtest du auch bei Outlook anywhere noch nie. Du kommst mit zwei Namen im Zertifikat aus. Einer davon ist autodiscover.

[PowerShellAdmin 169]

Die brauchtest du auch bei Outlook anywhere noch nie. Du kommst mit zwei Namen im Zertifikat aus. Einer davon ist autodiscover.

Danke - ja das war schließlich meine Annahme - aber manchmal schadet nachfragen nicht:)

[PowerShellAdmin 169]

Also ich habe hier extern immer noch vereinzelt Probleme - es läuft sporadisch...
 
Voraussetzungen:

-gültiges Zertifikat
-Postfächer und Public Folders sollten alle auf den Exchange 2016 migriert sein
-Auf sämtlichen Ex2016 Zugriffs Nodes muss .Net 4.5.2 oder neuer laufen
-Der Registrierungseintrag muss auf jeden Ex2016 CA Node gesetzt werden, falls nicht vorhanden (sollte mit 4.5.2 oder neuer automatisch gesetzt werden:
HKLM\Software\Microsoft\.NetFramework - DWORD "DisableRetStructPinning" Wert: 00000001
-Unabhängig von der .Net Version muss auf jeden Ex2016 CA Node auch folgende Systemvariable hinzugefügt werden:
Name COMPLUS_DisableRetStructPinning Wert 1
-Internal und External URL auf den MAPI vDirectories setzen
 
Auf jeden CA 2016 Node die Authentifzierung via PowerShell neu setzen - Ein Konfiguration via GUI ist hier nicht möglich (OAUTH nicht verfügbar) - man kann hier allerdings auch gleich via PS Internal und External URL anlegen und dabei die Authanbieter setzen:
 

Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm,Negotiate,OAuth

oder

Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -InternalUrl "https://mail.domain.tld/mapi" -ExternalUrl "https://mail.domain.tld/mapi" -IISAuthenticationMethods Ntlm, OAuth, Negotiate

Nun kann man MAPI over http auf der Organisation via PS aktivieren:

Set-OrganizationConfig -MapiHttpEnabled $true

Abschließend kann man noch den Dienststatur unter der URL https://mail.domain.tld/mapi/healthcheck.htm prüfen und in Outlook prüfen ob nun erfolgreich auf MAPI umgestellt wurde.
 
PS: Autodiscover Settings bei der Migration nicht vergessen und auf die Ex2016 Nodes umbiegen.

 

Quellen: Fachbuch MS ExchangE Server 2016 von Joos,  http://www.ugg.li/outlook-2016-gegen-exchange-2016-fragt-immer-wieder-nach-kennwort-mapi-virtual-directory-bug-in-exchange-2016-cu2/

bearbeitet 2. Oktober 2016 von PowerShellAdmin

[NorbertFe 2.035]

Ich bezweifle mal die registrykeys, dass das noch notwendig ist. Und ansonsten, bin ich mir unsicher, ob du eine Lösung beschreibst, oder ein Problem. ;)

[PowerShellAdmin 169]

Die Registry-Keys sind laut diversen Anleitungen sehr wohl notwendig, allerdings werden die mit den neuen .Net Versionen eigenständig erzeugt - Die Systemvariable nicht.

 

Ansonsten ist es eine Zusammenführung verschiedener Informationen, die meisten Einträge sind leider sehr unvollständig beschrieben, da freut sich sicher der Nächste über den Leitfaden - MCSEBoard ist bei Google immerhin schön oben.

 

Ja ich hatte sporadische Störungen bei Mapi over http, nun scheint es zu laufen - Die Aktivierung von MAPI setzt sich nicht sofort auf alles Nodes durch.

Bin derzeit noch in der Prüfung.

[NorbertFe 2.035]

Ich kenn das für 2013 und selbst dort ist es afair nicht mehr notwendig. Hast du eine Quelle, die das für 2016 beschreibt? Und das Mapi berechtigungsproblem kommt durch cu2 ist also mit cu1 oder cu3 nicht notwendig. ;)

[PowerShellAdmin 169]

@Registrierung

Also ich habe hier das Fachbuch vom Joos - hier wurde sicherlich auch viel aus Ex2013 übernommen und nur aktualisiert. Auf der Seite 581 ist es dort klar erwähnt.

Ich gehe davon aus, dass der Eintrag weiterhin notwendig ist. Ich habe jetzt noch mal nachgelesen, dass es mittlerweile durch die Installation von Ex2016 wohl automatisch angelegt wird.

 

@Berechtigung

Ex2016 CU2 war das Installations Medium und wurde auf CU3 aktualisiert => In meiner Umgebung waren die Berechtigungen weiterhin fehlerhaft.

CU3 ist sicherlich auch noch nicht überall verteilt - ist ja noch recht jung.

 

Also eine manuelle Korrektur ist also in meinem Fall zwingend notwendig gewesen, wer von CU3 aus startet, wird das hoffentlich umgehen können.

bearbeitet 2. Oktober 2016 von PowerShellAdmin

[NorbertFe 2.035]

Wenn du die Berechtigungen in der GUI mit cu2 durchführst, sind sie nach dem Update natürlich nicht auf einmal wieder korrekt. ;) du kannst sie in cu3 aber wieder in der GUI korrigieren. Wenn man gleich mit cu3 installiert tritt der Fehler logischerweise nicht auf. Ich gehe davon aus, dass man diesen registry Eintrag nicht braucht. ;)und schon gar nicht traue ich aktualisierten Papierbüchern, und schon zweimal nicht, bei dem Release Zyklus von Exchange. So :p kannst mir gern eine verlässliche Quelle geben.

[PowerShellAdmin 169]

Wovon du ausgehst ist an der Stelle nicht von belang, der Eintrag wird mittlerweile automatisch gesetzt - Im Gegensatz zu Systemvariable.

Inwiefern du jetzt versuchst die Probleme in CU2 zu relativieren kann ich nicht nachvollziehen - Es treten Probleme mit CU2 auf und man sollte das Ganze prüfen.

[NorbertFe 2.035]

Eben deswegen ist er ja nicht mehr nötig. passiert automatisch. Cu2 hatte den oben genannten bug. Ich relativiere nichts, sondern will verhindern, dass sich hier urban legends bilden, weils eben mal irgendwann so gemacht werden musste. Und du bist noch die Quelle für 2016 und die systemvariable schuldig geblieben. ;)

[PowerShellAdmin 169]

Da hast du nicht unrecht, ich lese hier zweideutige Informationen. Scheinbar ist der Systemvariablen Eintrag eigentlich auch nicht notwendig...

 

Wie auch immer - vielleicht kannst du mir hier ja weiterhelfen - Bei mir funktioniert der Outlook 2016 Zugriff nur sporadisch. Intern und Extern erhalte ich Verbindungsfehler, dann geht es wieder.

Unabhängig vom EXNode (testweise via Hostdatei geprüft ).

bearbeitet 2. Oktober 2016 von PowerShellAdmin

[NorbertFe 2.035]

Wieso Hostdatei? Ich denke du hast nen Loadbalancer?