PowerShellAdmin

Na Exchange Migrationen sind nicht mein tägliches Brot, da fehlt dann die Routine. Ansonsten lief bis jetzt alles recht gut, bis gestern Abend :-) Das Ding muss Dienstag laufen - alternativ muss ich einen "gangbaren" Weg finden um die Mapi Verbindung wieder richtig zu deaktivieren. Wenns jetzt weiterhin zickt, werde ich morgen Vormittag einen Critical Call bei MS öffnen, schaden kann es nicht. PS: Wenns läuft schulde ich dirn Kasten Bier ;) edit: Neben deiner Änderung (habe die Systeme auch nochmal sauber durchgestartet) habe ich testweise folgende Zeile ausgeführt um Mapi zu deaktivieren: Set-OrganizationConfig -MapiHttpEnabled $false Outlook funktioniert derzeit - Verbindung zeigt mir Mixbetrieb an (RPC und Mapi)- Die Durchsetzung dauert hier sicherlich- Morgen teste ich das Ganze nochmal, ob es so zumindest so funktioniert, im Anschluss schalte ich dann nochmal Mapi scharf über $true :) Ich mache jetzt mal Feierabend - Grippe und es reicht für heute!

Danke Norbert - werde das Ganze mal testen. Mir sind die Probleme erst im Anschluss zu Umstellung auf MAPI aufgefallen. RPC over Http müsste ich noch mal erzwingen und gegen prüfen. Ansonsten ist der Ex2010 weitesgehend abgerüstet, keine Datenbanken mehr vorhanden, lediglich die Empfangsconnectoren sind hier drauf noch aktiv. Aber hier sollte es eigentlich keine Probleme untereinander geben.

Ja den LB kann man ausschließen. Bzgl. Throttling - kannst du mir das vielleicht noch etwas konkretisieren ? Danke.

Ja habe ich intern- habe das Ganze via Host-Datei auf die einzelnen Nodes umgelenkt. War leider die selbe Problematik.

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 ).

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.

@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.

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.

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/

Fehlermeldung: mangelnde Berechtigungen. Also wird der Ausführungsbenutzer keine Berechtigungen auf die Verzeichnisse haben. Ursächlich liegt das Ganze am Recurse, da hier weitere Eigenschaften abfragt werden, für die du Zugriff benötigst. Also wie beschrieben, Berechtigungen setzen oder den Fehler ignorieren.

Lässt sich das nicht organisatorisch lösen - Email erneut anfordern z.B. Da ihr wisst, dass eine Email fehlt, sollte ihr auch wissen welche.

Na die A Record Abfrage beim Domainanbieter, gibt ja zwei IPs zurück. (Beispiel) A mail.domain.tld 85.123.123.50 A mail.domain.tld 95.123.123.50 Nun erfolgt z.B. der Abgleich vom PTR mail.domain.tld 95.123.123.50 -> Prüfung PTR vom ISP => erfolgreich -> Abfrage A Record beim DNS der Domäne => erfolgreich (2 IPS) -> Abgleich A Record DNS mit PTR => Ja die Menge ist vorhanden, aber ich hatte was gelesen, dass es ein 1:1 sein sollte.

Da ich mir nicht sicher bin, ob das Verfahren so zulässig ist und hier 2 Rückgaben verarbeitet werden.

So - sehe ich folgendes richtig - also Round Robin auf den SMTP FQDN, dass hier draus ein Mismatch resultieren kann oder ist das so zulässig? Eine DNS Query auf mail.domain.tld gibt mir zwar beide IPs korrekt zurück, ebenso funktoniert ja auch der PTR ... Aber tun sich hier die Spamfilter verwursteln? SMTP Connector: fqdn:mail.domain.tld Provider: A Record: mail.domain.tld [iP ISP1] A Record: mail.domain.tld [iP ISP2] ISP 1: [PTR IP] mail.domain.tld ISP 2: [PTR IP] mail.domain.tld

Ah alles klar - dann habe ich das falsch verstanden ;) Asche über mein Haupt.

Umgekehrt richtet man es aber immer ein, da es einen Fallstrick darstellt. Eben weil es üblich ist, ganz unabhängig davon dass es nicht klar gefordert ist, nun mal ein schwebender Standard. Ebenso hilft es einen nicht weiter, wenn diverse Empfänger nicht erreichbar sind, was offiziell vor einigen Jahren verabschiedet wurde.

Und was wäre deiner Meinung nach hier der einfachste Weg ?

Schade mein Ansatz ist doch immerhin "kreativ" und lässt sich einfach integrieren. Intelligenter Router zu Verwaltung beider Verbindungen? Die Leitungen waren bisher organisatorisch getrennt. Wäre aber ein Ansatz - hast du hier eine Hardware-Empfehlung?

Ersteres - ist nur eine kleine Umgebung.

So wegen dem SMTP Connector habe ich mir jetzt nochmal Gedanken gemacht. Der Failover klappt ja nur Dienstbezogen nehme ich an, Störungen an Internetanschluss werden so wohl nicht verarbeitet. Lösungsansatz: PS Skript auf jeden Node als Job - Falls bei der Prüfung eine Störung auftritt wird der Node aus dem SMTP Connector entfernt, umgekehrt bei erfolgreicher Verbindung wieder ergänzt. => Kann die Live Umschaltung zu Störungen des Nachrichtenflusses führen?

Danke - dann bleibe ich beim ursprünglichen Ansatz:) Mail eingehend: 2 A Records, Prio 10 mail01.domain.tld , mail02.domain.tld Clientzugriff extern:2x A Records auf mail.domain.tld ( Round Robin auf internen LB) Clientzugriff intern: A Record auf LB Ausgehend 1 SMTP Sendconnector mit beiden Membern - fängt Nodeausfall, aber keine Störung an der Internetleitung ab oder wie intelligent ist das Ganze?

Also der eingesetzte LB ist nur eine freie Instanz von Kemp ohne Support und limitiert. Hier werde ich mir mal Angebote einholen. Ich dachte dass zwei gleichpriorisierte MX Records für diese Konstellation eine saubere Lösung sind. Das andere Thema ist, dass der LB ja über bei Internetanschlüsse von außen ansprechbar sein sollte. Entsprechend war auch meine Annahme, dass ich für den LB am DNS eine RoundRobin mit beiden Anschlüssen setzen muss.

Kleine Ergänzung: Da die MX Records ohne Round Robin umgesetzt werden, müssten diese also Mail01.domain.tld, Mail02.domain.tld lauten. Der Clientaccess würde dann weiterhin via mail.domain.tld über Round Robin laufen

Ich setze derzeit eine Exchange 2016 Umgebung ein und mache mir hier einige Gedanken bzgl. einer für uns sinnvollen Abbildung. Das Thema DAG und HA ist für mich auch etwas neu, also zereißt mich nicht gleich, falls hier schwerwiegende Mängel vorhanden sind. Exchange 2016 DAG - 2 Nodes, 1 Witness Jeder Node hängt an einem IPS Jedes Node läuft auf eigenen Vsphere Server Jeder Node hat eine DB - kreuz gespiegelt. Postfächer ~60 ESET Mail Security Internetanschlüsse: 2 LB: Testweise Kemp VA, vorstellbar auch Sophos UTM - scheint ja auch zu laufen. Intelligentes Loadbalancing: nicht erforderlich 1. Client Access 1.1 Intranet-Company Mail.Domain.tld -Round Robin oder Load Balancer ~ Abwegung läuft Nachteil 2 LB benötigt für HA 1.2 Internet-Außerhalb ->Round Robin auf mail.domain.tld (so wie ich das sehe, auch bei 2 LBs notwendig oder wie konfiguriere ich das hier sinnvoll, jeder Eintrag verweißt auf einen Anschluss) 2. MX Records 2 Records, selbe Prio, mail.domain.tld, mail2.domain.tld -> verweisen auf unterschiedliche IPS, werden vom Router an die Nodes weitergereicht. 3.SMTP 1 SMTP Connector für den Bereich, beide Server als Member zugewiesen. Jeder Server versendet über eigenen ISP raus => Fragen @1.2 => Wie setzt man LBs sinnvoll von außen hinter 2 ISPs sinnvoll ein. MAcht man das üblicherweise bei dem Clientaccess ohne Round Robin und wie bildet man das Ganze dann ab? @3 Der SMTP Connector im Exchange 2016 hat hier a) eine Lastenverteilung und merkt B ) falls ein Server ausfällt => Problem: Wie kann verhält sich das, wenn hier hinter eine Störung auftritt, Verkabelung, Router, IPS? @Greylisting via MailSecurity: Kann ich das in diesem Setup überhaupt sinnvoll einsetzen oder kann es dazu führen, dass die SMTP Zustellung zwischen beiden Nodes springt- idealerweise sollte Mailsecurity ja die Clients koordinieren oder? @LB: Dachte hier an 2 Sophos 120 UTM, die Kosten für die SA müsste ich entsprechend nochmal kalkulieren. So erstmal besten Dank, ich freue mich auf euern Input :)

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