PowerShellAdmin

Nutzt du Mapi over https? Tritt das Problem nur bei Clients mit mehreren Postfächern im Profil aus? Dann kram dir meinen alten Thread aus und teste das Ganze mal oder deaktiviere Mapi over https

Hallo Magheinz, das Ganze ist derzeit aktiv via Catchall und Pop3-Abruf (ein kleines aber großes Chaos ;) mit noch einigen anderen Verbrechen) was ich derzeit sortiere und dann direktes Mailing umstellen. Das Ganze sieht aktuell so aus: ^[string]\d\d\d\d@domain.tld also Anzeige1111@domain.tld Wenn es zukünftig Anzeige+1111@domain.tld hätte, wäre das auch kein Problem. Die verwendeten / aktiven Schaltungen würde ich temporär statisch einpflegen. VG PSAdmin :)

Transportregel mit den obigen Regeln auf einem Edge Server würde ja schon funktionieren ;) Auf einen Edge Server würde das Ganze vor der Prüfung auf eine existierende Mailadresse stattfinden, auf einem Hubserver ist das nicht möglich. Im Prinzip ist das Ganze ein Catchall Postfach auf dem Exchange, wo man allerdings via RegEx die Menge wiederrum reduziert. So wie ich das derzeit sehe, gibt es hier so nur zwei Lösungen: -Edge Server aufbauen & Transportregel -Dein Vorschlag - Hosterseitiges Catchallpostfach auf eine Subdomain/andere Domain und eine optionale nachträgliche Auswertung => ihgitti Gibt da schon kreativie Lösungansätze :) z.B. [string]YYMM[0-8 pro Monat]@domain.tld, das Ganze wird monatlich per PS Skript auf das Postfach aktualisiert (Zeitraum -10 Monate bis +10 Monate). Ich bin derzeit eher an der organisatorischen Ebene dran ;)

Ja die 500 hatte ich im Hinterkopf - die Empfehlungen waren aber weit drunter. Man bläht sich damit das Ganze Ad-Objekt auf. Die Transportregel wäre perfekt gewesen :/

Abend ;), das mit der Subdomain wäre ein Ansatz, ein ähnliches Konstrukt hatte ich bereits im Hinterkopf. Das Ganze wäre aber gegen jede Integrität und sollte daher wirklich vermieden werden. Es sollen die vierstellige Nummer immer mit übergeben werden, damit die Email entsprechend zugeordnet werden kann. Meiner Meinung nach wäre hier der Betreff der richtige Ansatz, allerdings unterschätzt man hier wohl den Benutzer. Das Ganze ist für eine Zuordnung von Chiffre/Anzeigen gedacht... VG PSAdmin

Moin, ich möchte derzeit ein Postfach einsetzen, auf das 10.000 eingehende Adressen gehen. Sieht etwa so aus: [string][4 int]@domain.tld Umgebung: Einzelsystem mit Ex2010 ohne Edge Server. Option a) Der Ursprungsgedanke war eine Transportregel zu erstellen - hier mit RegEx (^[string]\d\d\d\d@domain.tld)- und sämtliche eingehenden Emails auf ein Postfach umzulenken. Endet in einen NDR, die Empfängerfilterung ist auf dem Exchange deaktiviert. b) Adressen auf ein Postfach setzen - allerdings liegt hier das empfohlene Limit bei ~200. c) Organisatorisch lösen - mein eigentlich bevorzugter Weg So wie ich es rausgelesen habe, muss die Regel a) generell funktionieren, ist so allerdings nur auf einen Edge-Server lauffähig. Ist das tatsächlich so, gibt es hier vielleicht doch noch eine sinnvolle Alternative? VG PSAdmin :)

Dann zitiere ich mich mal selbst Habe ich mir schon gedacht, nen fixes Rename auf die Organisationsdomäne und gut ist ;)

Sieht ansich auch schon viel besser aus, die Domäne innerhalb der MessageID ist unschön. Gibt es eine Möglichkeit diese zu beeinflussen, diese läuft ja auf den FQDN des Mailservers. Warum - Isso. Manchmal sind Trennungen nunmal gewünscht.

Besten Dank Norbert :) ! Werde mir das jetzt nochmal in der Tiefe anschauen, da dort die Domäne vollständig raus soll (auch bei generierter Server usw).

Moin, Im Emailtrace soll die interne Domäne der Exchangeorganisation manipuliert werden, also durch eine andere ersetzt oder komplett entfernt werden. Ich habe im Hinterkopf, dass man hier die Finger von lassen sollen, da der SMTP Trace im SMTP RFC festgehalten ist. SVR.domainorg.tld dann zu svr.domainnew.tld oder komplett raus. Für den Exchange 2010 kann ich das Ganze wohl entfernen via: Get-SendConnector “Connector Name” | Remove-ADPermission -AccessRight ExtendedRight -ExtendedRights ms-Exch-Send-Headers-Routing -user “NT AUTHORITY\Anonymous Logon” Hier würde mich nochmal eure fachliche Meinung interessieren :) Danke & VG PSAdmin

Und durch die Port Änderung wird deine http Verbindung also sicherer und ist auf einmal nicht mehr unverschlüsselt? :shock: Wenn ich das schon lese, würde ich erstmal hinterfragen, ob die gesetzlichen Rahmenbedinungen für die Nutzung überhaupt erfüllt sind..

Grundlegend solltest du erstmal die Zugriffe für den Splittdns definieren und daraus dann deine Zertifikatsanforderungen ableiten. Im Anschluss solltest wirst du dann üblicherweise eine SAN Zertifikat benötigen, welches mehrere FQDN abdeckt.

Am besten gleich nen richtiges SAN Zertifikat nehmen und sich freuen ;), wieviel Probleme und nervige Anfragen man in Zukunft umgeht.

Das Computerkonto benötigt explizit zugriff auf das Zertifikats-Template. edit: hier bei Frankysweb siehst du den entsprechenden Eintrag - einfach im Browser suchen: "Auf dem Reiter Sicherheit bekommt die Gruppe “Exchange Servers” Vollzugriff auf die Vorlage" https://www.frankysweb.de/exchange-2013-san-zertifikat-und-interne-zertifizierungsstelle-ca/

Die meisten Programme bieten hier ja nur eingeschränkte Konfiguration. Ich meine im ORF war auch nur die Option, dass man das Ganze bereits bereits ab Softfail aktiviert. Eine richtige Differenzierung ging da aber auch nicht. Eset Mail Security hat es erst diesen Sommer hinbekommen, eine SPF Verarbeitung zu integrieren ........ Hier kann man es aber lediglich aktivieren, der deutsche Support war mit meiner Frage ob das auf Soft- oder Hardfails reagiert überfordert (gehe nur vom letzteren aus). Wird ORF eigentlich momentan weiter entwickelt? Die 5er wurde ja für 2013 released, ist aber supported für 2016. Gibt auch bei dem kleinen feinen Tool potential führ Erweiterungen :) - ich will es ja eigentlich immer noch .... So ich ruf jetzt mal wieder bei Eset an ... Seit 3 Wochen nen Call offen (Mailsecurity Hosts lizenzieren sich beim Lizenzserver ständig neu - mehrfach).

Bzgl. SPF fällt mir Paypal ein :), das Thema Softfail ist am SPF Design auch nicht zu ignorieren. Damit hebt man zwar die Echtheit der definierten Server an, schließt den Rest aber nicht aus. Beispiel ist oder war zumindest Paypal, hier war halt nur ein ~ und nicht - ..., was leider diverse Anbieter machen um Probleme / schlechte Pflege zu umgehen Ich würde: Hardfail: Rejecten Softfail: wenigstens Spamzuordnung/Junkmail Bzgl.Office Thematik und Dateianhänge: -Reject all oder wenigstens ausführbare und gefährliche (html, js, Ps,bat uvm.) Endungen, dazu eine Whitelist setzen: Docx & co sind nunmal keine so großen Monster wie die veralteten Vorgänger, Docm & co sollte man natürlich aussperren. Wer eine Qurantäne nutzen möchte, muss auch die Einhaltung des Datenschutz prüfen ( wurden private Emails untersagt?). Zusätzlich kommen die Anhänge ja mittlerweile auch indirekt über Links und Verweise - Hier muss man die Benutzer warnen. Dazu sollte man auch die Backups überdenken, z.B. die Sicherung von Freigaben über Syncronisation mit Versionierung und einiges mehr. Zum Thema - einfaches Spoofing konnte man doch bereits mit Boardmitteln vom Exchange aussperren - Hier muss man schauen, dass externe Anwendungen natürlich die Exchange Organisation zum Mailversand nutzen. http://www.packetland.net/microsoft/exchange-server/123-how-to-prevent-internal-spam-from-your-own-domain-on-exchange-2010.html

Regelmäßige Vollsicherung zu Reduktion der DB-Logs hattet ihr aber immer ausgeführt? Sind einige Objekte gelöscht worden vor paar Wochen und der Dumpster hat sich nun geleert? Wurden Arbeiten gestern/heute am Exchange ausgeführt?

Die neue Umsetzung sehe ich jedenfalls nicht als empfehlenswert, denn die Umsetzung führt in der Anwendung zu einem unsicheren und fehleranfälligen Zustand, sobald es Änderung an der eigentlichen Theme gab. Updates werden schließlich nicht auf die Themes mit übernommen und müssen eben nach jedem Update wieder nachgepflegt werden - sprich das Theme aus dem original neu erstellen und die Änderungen wieder nachpflegen. Ebenso können hier fehlerhafte Anpassungen das Ganze weiter destabilisieren. Ich persönlich würde so garnix umsetzen wollen.

Ich finde das garnicht so lustig und betrachte solche Punkte sehr kritisch. Im ex 2010 gingen die Customthemes aber noch nicht oder? Geht ja in die richtige Richtung. Allerdings sollten Themes immer differentiell sein, so dass nur die geänderten Dateien enthalten sind - analog wie z.B. in WordPress und dortige Childthemes.

Workflow Lösung einsetzen, am besten die Jobconf in ne Tabelle DB schreiben und hinten dran nen passenden Powershell Job triggern;) Funktioniert wunderbar und der Benutzer benötigt keine entsprechenden direkten Zugriffe.

Ja die Gui bei PS ist nicht sonderlich, auch die Gridausgabe ist mehr oder kaum brauchbar - Man kann leider keine Aktionen in der Grid hinterlegen. Im Regelfall reicht aber die Konsolenausgabe aus - auch wenn es nicht toll aussieht... Nachteilig (oder auch nicht) sehe ich dass du eine Anwendung aus dem Skript erzeugst, gerade wenn zügige Anpassungen gewünscht sind, ist das natürlich ungünstig. Im Regelfall soll die PS Vorgänge automatisieren und verarbeiten, als Ergebnis erhalte ich dann eher einen Report via Mail, DB Zugriffe, oder auch Flatfiles usw... Hier und da wäre eine Gui schick, aber wirklichen Bedarf hatte ich noch nicht. Für richtige Workflows würde ich eher auf eine passende Lösung setzen, wo dann vielleicht wieder die PowerShell im Hintergrund werkelt und dann z.B. als Job auf eine DB zugreift und entsprechende Benutzer anlegt usw... Ja .Net kann der PS hier und da den ars*** retten, manchmal ist aber ehrlichweise dann die PowerShell auch das falsche Werkzeug was man nutzt ;)

Gibts hier eigentlich Infos von MS ob das zukünftig auch mal besser wird? Eine einfache Lösung zum anpassen der Logos und des Menüs würde ja wohl 99% der Anwender glücklich machen.... Hier könnte man ja die OWA Policies ausbauen... Derzeitig würde ich da garnichts anpassen, nichtmal das Logo austauschen.

Also für mich fällt der Postgeheimnis klar unter Datenschutz :jau:

Das ist aber der falsche Ablauf! Derzeit ist es (falls nicht lizenziert) ein Verstoß und möglicherweise auch strafbar. Erst die Lizenz, dann die Umstellung.

Mapi over http lässt sich definitiv nur auf Postfachebene aktivieren (hier gibt es ein Benutzer Attribut). Man sieht das Ganze dann auch ganz toll in Outlook, welche Profile über Mapi oder welche über Outlookanywhere zugreifen... Set-CasMailbox <user or mailbox ID> -MapiHttpEnabled $true Mapi over http lässt sich aber -wie üblich- auch organisationsweit aktivieren Set-OrganizationConfig -MapiHttpEnabled $true Was ich nicht getestet hatte, ob man organisationsweit aktivieren kann und sich dann auf Postfachebene einzelne Zugriffe deaktivieren lassen- gehe aber davon aus, dass sich diese Richtung umsetzen lässt ($null - default, $false, $true) Und hier die Fakten: https://technet.microsoft.com/de-de/library/mt634322(v=exchg.160).aspx Die Einzelaktivierung empfand ich beim Debugging sehr hilfreich ;) Man will ja nicht gleich das ganze Mailing flachlegen. PS: Dem MS Pro Support war das Setting aber auch vonsichaus wohl nicht so bekannt, der war auch erstmal irritiert.