Wolke2k4

Hallo zusammen, ein Kunde fragt an, möchte EWS gern für Anbindung eines Fachverfahrens nutzen. Zugriff soll aus dem Internet via 443 auf den Exchange erfolgen. Wir könnten zwar einen bereits in Benutzung befindlichen Reverse Proxy (Windows Host) hierfür mitnutzen. Aus Sicherheitsgründen wollen wir künftig aber alle Kunden mit RP Lösungen auf VPN only umstellen. Mir gehts jetzt aber speziell noch mal um das EWS: Verstehe ich doch korrekt?: 1. EWS wird nicht mehr weiterentwickelt? 2. EWS ist ein Dienst, der wenn aus dem Internet verfügbar gemacht wird, letztlich genauso anfällig gegen Angriffe ist wie OWA und Active Sync? 3. Noch etwas in Bezug auf die Sicherheit was den EWS anbelangt und gegen den Einsatz über Portforwarding WAN zu DMZ (RP) zu LAN spricht? Danke für euer Feedback.

Tatsächlich war es am Ende die falsche Absender IP der Firewall, mit der der Exchange verschickte, die zu den Problemen geführt hat. Man hat es dann mit einem Postfix als Versendelösung umgesetzt.

Um das Problem kümmern sich jetzt die Verursacher... Trotzdem Danke für die Rückmeldungen!

Die Frage stellte sich mir unabhängig von dem Queue Problem...

Geht nur allgemein darum: Exchange 2010 bis 2019 IPv6 = aktiviert lassen oder nicht?

Hallo zusammen, soweit ich mich erinnere ist für Exchange 2010 zwingend IPv6 erforderlich. Für alle Versionen danach scheint das nicht mehr der Fall zu sein? In den offiziellen Requirements ist dazu jedenfalls nicht eindeutig etwas zu finden, dass es zwingend notwendig ist... Trotzdem gibt es aber auch noch Artikel im Netz, die bspw. bei Exchange 2013 und deaktiviertem IPv6 von Problemen berichten. Wie sind eure Erfahrungen?

Den Artikel hatte ich auch gefunden, die Befehle nimmt der 2013-er aber nicht... Das vorgeschaltete Gateway leitet ungefiltert alles auf Port 25 zum Exchange... die Queue ist derzeit 14GB groß...

Hat mal jemand einen Befehl für mich, mit dem ich die Mail Queue eines Exchange 2013 leeren kann... scheinbar ist der Echange zur Mailschleuder geworden... Alle Befehle die ich bisher gefunden haben, funktionieren nicht...

Danke, den hatte ich zuerst gesehen aber die Anpassung ließ die Warteschlange nicht kleiner werden. Es gibt allerdings noch einen Missmatch zwischen A Record des MX-er des Kunden und der dazugehörigen IP. Denn aus den Abuse/Mailerdaemons der Empfangsserver geht hervor, dass der Kundenserver/Exchange mit einer anderen WAN sendet… Hier vermute ich, dass die Empfangsserver einen einfachen Check durchführen, der fehlschlägt und daher von vielen Mailsevern die Zustellung abgelehnt wird. würde auch erklären, warum andere Mailsserver die Mails schon annehmen… bspw. Outlook.com… Gegenteilige Einschätzungen zu meiner Theorie?

Das haben wir seit Jahren auch in den Citrix Umgebungen nicht mehr genutzt... eben weil die Leute es nicht raffen. Darüber hinaus hat Citrix mit veröffentlichten Anwendungen immer wieder Probleme und Bugs gehabt, sodass wir dann schlussendliche vor Jahren auf den Deskotp umgestiegen sind. Dieses Experiment möchte ich mit RDS nicht auch noch machen, reicht mir schon diese Baustelle. Trotzdem Danke für den Vorschlag. Ja benötigen sie...

Hallo zusammen, ich habe hier einen Kunden, der will über den Exchange direkt versenden... der SMTP Banner entspricht aber im Sendekonnektor dem lokalen SMTP Namen... das führt mit der bisherigen Konstellation mail.externe-domain.de zu problemen, denn der Exchange erscheint mit exchange.interne-domain.de... Ich hab schon gesucht aber ich finde keine Möglichkeit diesen SMTP Namen/SMTP Banner vom Exchange auf den Hostnamen mail.externe-domain.de zu ändern. Solche Experimente haben wir bisher bei den Kunden aus entsprechenden Gründen vermieden und stets über andere Smarthosts verschickt... Wenn ich das hier richtig gegooglet habe, lässt sich im Sendekonnektor der Bannername aber nicht ändern, im Empfangskonnektor aber schon, was mir hier wohl aber nicht wirklich hilft?

Klingt auch nicht wirklich wie von MS gewollt und von hinten durch die Brust. Ist also weiterhin so, dass MS hier für diese Umgebungen nichts sinnvolles vorsieht. Friss oder stirb heißt es dann aus Redmond... Veröffentlichte Anwendungen ist kein Thema, dazu sind die Nutzer zu doof und würden dann mit dem lokalen System interagieren... brächte also nur noch mehr Ärger. Was heißt: "Alternative Benutzeroberfläche"?

Hallo zusammen, gibt es einen zuverlässigen und einfachen Weg das Startmenü in Gänze tot zu legen?

Hallo, hat jemand eine Idee, wie man Termin in Outlook auf eine einzeilige Darstellung umstellen kann? 2010 konnte das von Haus aus, soweit ich das hier sehe, ist das ab 2013 aber nicht mehr so...

Hallo zusammen, über manche Dinge macht man sich weitergehend keinen Kopf. Man nimmt an, dass das was man einstellen kann das ist, was zum Ziel führt. Getreu dem Motto "viel hilft viel", wird dann schon mal durchaus Murks eingestellt. So beim Thema vCPUs unter Hyper-V. Ich habe die letzten beiden Tage einige Artikel gesucht, gelesen, vieles ist da mit Details garniert, die mich garnicht interessieren sondern ich suche etwas praktisches, mit Beispielen. Auch hier im Forum gab es bereits Beiträge dazu, verweise auf diesen Artikel, der auch schon entsprechend als ist. Mich würde daher folgendes interessieren: 1. Hat noch jemand einen leicht verständlichen und relativ aktuellen Artikel zum Thema? 2. Wie stellt Ihr eure VMs bezüglich vCPUs ein? 3. Mich interessiert insbesondere die Dimensionierung bei virtuellen RDS Servern. Und ja auch diesen Artikel kenne ich, der schlussendlich besagt, dass es keine allgemeingültige Empfehlung gibt...

Ich habe aktuell 2 Kunden mit RDS und Performanceproblemen. Sind 2 Schulen... In beiden Fällen Hyper-V Server als Host, hatten vorher 2008R2 RDS drauf, da gab es keine derartigen Probleme. Nun sind es 2019-er Server... Wir sind derzeit noch bei der Ursachensuche.

Kann man über einen PS Befhel checken wie die Einstellungen derzeit sind? Damit lassen sich doch sicher die Werte ändern? Mir gehts erstmal nur darum den Ist-Zustand einzusehen. Dein Einwand macht natürlich Sinn...

Moin zusammen, bin leider nicht so recht fündig geworden... Kann man dem Empfangskonnektor des Exchange (geht um 2016) sagen, dass er mehr als 128Bit nutzen soll? Das ist doch keine Einstellung im Konnektor sondern irgendwo in der Chiper Suite? Ich hatte mal im Rahmen der Absicherung eines RP dieses schöne Tool gefunden, aber das ist ja für den IIS. Der sollte SMTP ja keine Rolle spielen? Sorry falsches Forum erwischt, kann das jemand verschieben?

Danke für den Input, habe es bei einer entsprechenden Firewallregel belassen und im Empfangsconnector den Quellserver natürlich noch erlaubt. Damit ist sowohl auf Firewall Ebene als auch auf Konnektor Ebene der Kreis der IPs, die diesen Eingangsweg/SMTP nutzen kann quasi aufs absolute Minimum reduziert. So betrachtet hattet Ihr sicher Recht, spart man sich die Veröffentlichung von AD Daten beim Third Party Anbieter...

Nun würde ich aber dennoch gern die Auth Möglichkeit nutzen wollen... und nun?

Ich glaube wir reden hier von unterschiedlichen Themen... Der NSP kann dem on Prem Exchange Mails zustellen. Das kann er über 2 Wege: mit und ohne Auth. Ist doch wie bei iSCSI, da kann ich, muss ich aber kein Auth einrichten... Nach Deiner Argumentation müssten dann ja sämtliche Mailprovider ihre Server offen wie ein Scheunentor belassen und ohne Auth SMTP Anfragen annehmen können...

IP Einschränkung per Firewall hatte ich sowieso vor. Den letzten Sicherheitsschliff wollte ich aber gern eben mit Authentifizierung umsetzen. Wieso sollte der Exchange keine SMTP Auth Anmeldung entgegenehmen können? Selbst wenn ich dafür einen separaten/eigenen AD Nutzer erstellen und benutzen würde, würde das doch der Sache genüge tun...

Ja das geht, wurde auf Nachfrage mehrfach bestätigt. Das die Handouts/Whitepaper und die Online Hilfe so auf 365 getrimmt sind hatte ich bereits beim Vertrieb kritisch angemerkt...

Ist der Nospamproxy Cloud. Ist erster MX, schickt dann an den Exchange/die internen Empfänger...

Hallo zusammen, ich möchte von einer Third Party SMTP Lösung aus dem Internet an einen Exchange Mails schicken lassen. Der 3rd Part Mailserver muss sich am Exchange via TLS und SMTP Auth authentifizieren. Ich würde jetzt einen separaten Frontend Empfangsconnector erstellen und TLS aktivieren. Bei den Auth Einstellungen bin ich mir nicht sicher. Nur TLS zu aktivieren wird wohl nicht reichen, denn irgendwie muss ich dem Connector beibringen, dass er nur mit Benutzername und Passwort SMTP reden darf... Wahrscheinlich muss ich auch noch irgendwelche Powershell Befehle abfeuern, damit das Ganze läuft (bspw. das hier: https://docs.microsoft.com/de-de/exchange/clients/pop3-and-imap4/configure-authenticated-smtp?view=exchserver-2016)? Was ich bisher im Netz und hier im Forum gefunden habe, hilft mir nicht so recht weiter...