Alle Aktivitäten

Danke, Norbert, daraus werde ich lernen. Also, was die Zertifikate angeht, kann ich schon alles über EAC machen? (Das ist so gut/stabil wie per Shell?) Das self-signed Zertifikat kann ich über EAC - Zertifikate erstellen? Das ist dann ok? Und wie würde ich dieses self-signed dann fürs Backend hinterlegen, wenn man es nicht über IIS machen soll?

Falsch. Exchange Zertifikate importiert man entweder per Powershell oder neuerdings auch wieder über die EAC. Falsch, auch das macht man nur per Powershell oder EAC. IMMER! Nein, da nimmt man nicht das Microsoft Exchange Server Auth Certificate. Man nimmt das self signed certificate mit dem Servernamen des lokalen Hosts. Und genau deswegen macht man das nicht per IIS, weil der Exchange dann seine Konfiguration wieder "gerade" zieht. Und das ursprüngliche Zertifikat hast du ja gelöscht ;)

Ich habe (nach Anleitung des bisherigen Admins) das SSL über das Zertifikats-Snap-In importiert, dann bei den Bindungen ausgewählt. Dann über Shell bzw. EAC geschaut, welche Dienste dran hängen und vorsorglich diese noch explizit zugewiesen. Das wäre meine nächste Frage gewesen, ob das Backend Zertifikat auch das gekaufte sein muß, da dies ja nur die Backend-Dienste innerhalb des Servers betrifft. Sprich, da kann ich das Microsoft Exchange Server Auth Certificate nehmen? Seltsam ist aber, dass es jetzt 3 Wochen lief bzw. jetzt 2 x sonntags ein Problem gab (im Abstand von 2 Wochen). Samstagabends wird der Server immer neu gestartet (wg. Updates), offenbar muß das Backend-Zertifikat dann rausgeflogen war, da heute morgen keines ausgewählt war.

Administrators, zwei der Transaktionslogs SYSTEM. Das Phänomen hat sich bei den jüngsten Windows-Updates nicht wiederholt.

Ja genau, halt das "Extended Use Right", das gibt's weiterhin nur für EA/OV

Du meinst Serverlizenz?

Nein. Dieser Passus wurde bereits im Oktober 2022 hinzugefügt. Vor dem Oktober 2022 konntest du bspw. den Exchange mit SA kaufen und die CALs brauchten damals keine SA. Seit dieser Änderung müssen auch die CALs eine aktive SA haben, um auf Produkte unter SA zuzugreifen. Das ist "nur" ein Hinweis, dass sich der folgende Part "nur" auf Subscription Licenses und Lizenzen unter aktiver SA bezieht. Ans Ende des Satzes "Subscription License or licenses with active Software Aussurance only" müsste meiner Meinung an der Stelle ein Doppelpunkt. Beim Exchange SE oder auch bei Skype for Business SE fehlt ein Satz wie dieser beim Sharepoint SE / Project SE:

Moin zusammen, wir haben derzeit Probleme Mails mit verschlüsselten Zip Dateien im Anhang zu erhalten. Der vorgeschaltete NoSpamproxy meldet dazu das die Mail vom Exchange abwiesen wurde, nur finde ich kein Logging dazu auf dem Exchange. Die Meldung "5.0.0 Virus found inside of the email" kommt aber vom Exchange oder was meint ihr?

Und hast du danach mal im iis nachgeschaut? Das backend Zertifikat ist übrigens nicht das gekaufte sondern immer das selfsigned Zertifikat.

Den Einwand verstehe ich nicht. Der Passus, den ich zitiert habe ist aus den aktuellen Product Terms vom Exchange Server SE, die du selbst verlinkt hast. Und da steht doch eindeutig bei den Server Lizenzen; "Subscription License or licenses with active Software Aussurance only". Da drunter kommt dann der Passus zu den Access CALs: "All CALs used to access the software under this model must also be acquired as subscription licenses or have active Software Assurance" Da brauchts doch diesen Zusatz, wie der Sharepoint SE den hat gar nicht, oder? Weil man braucht entweder eine passende Subscription Lizenz oder Lizenz mit SA, sowohl für Server als auch Access CALs. Liest sich für mich recht eindeutig.

ok, verstehe. Mit der Shell habe ich das Zertifikat den Diensten zugewiesen. Mir ist bewusst, dass man alles mit Shell machen kann. Mit der "GUI" ist es natürlich einfacher/schneller. Dann werde ich mir mal die entsprechenden Cmdlets zusammensuchen. Vielen Dank

Das steht "schon ewig" da und bezieht sich nur auf Server / CALs, die mit SA erworben wurden. Bzw. wurde das zum 01.10.2022 ergänzt. Beim Exchange SE fehlt meines Erachtens weiterhin der Passus, den ich oben für Sharepoint SE zitiert habe.

Inzwischen gibt's da unter "Licence Model" den Passus: Server Licenses (per Instance) For Products under the Server/CAL License Model, customer may use one Running Instance of server software in either a Physical OSE or Virtual OSE on a Licensed Server for each License it acquires. Subscription licenses or licenses with active Software Assurance only. Zudem haben sie jetzt auch endlich die CAL Equivalents angepasst, damit ist nun auch offiziell. dass die M365 E3 Lizenzen zumindest die User CALs immer beinhalten. Server CAL aber weiterhin nur im Enterprise Agreement und OV,

Dann macht der bisherige Admin das auch falsch. Das machst du auch über die Exchange Shell, ebenso wie man das Zertifikat auch möglichst nicht über die MMC importieren sollte. Manuell sollte man im IIS nichts anfassen bei Exchange, da hat Norbert absolut recht. Das gibt im Zweifel nur komische Probleme.

Vielen Dank für die Rückmeldung. Ja, ist natürlich klar, dass das keine Fehlermeldung ist Ich habe das gestern Abend von zuhause aus kurz gecheckt und mal eine erste Analyse abgeben und heute im Büro genauer danach schauen und Rückmeldung geben. Aber offenbar ist es gelöst, ich habe das hier gefunden: https://www.act-computer.de/hilfe-tipps/item/geloest-outlook-verbindet-sich-nicht-mehr-mit-exchange-2016 Nach Eintrag im Exchange Back End ging es wieder. Ich danke euch für eure Bereitschaft. Grüße Christoph Danke, aber ich muß doch bei den Bindungen das neue Zertifikat für https auswählen oder geht das rein über Shell auch? (So hat es mir der bisherige Admin gezeigt)

Im iis sollte man üblicherweise gar nix machen hinsichtlich Exchange und Zertifikate. Was genau machst du da?

Moin, "geht nicht" ist keine Fehlermeldung. Was geht denn genau nicht? OWA ist ja im Browser zu öffnen - wirft der Browser Zertifikatsfehler (welche)? Oder wirft Exchange Code 500?

Hallo, es geht um Exchange 2016. Am 03.07. ist das alte Zertifikat abgelaufen. Ich habe rechtzeitig bei InterSSL das Zertifikat verlängert und aus der -key und -crt Datei eine -pfx-Datei erstellt. Dieses habe ich vor Ablauf des alten Zertifikats am Exchange importiert und das alte dann gelöscht. Im EAC bzw. Shell für die Dienste IIS, IMAP, POP, SMTP aktiviert. Im IIS das neue Zertifikat für https/443 ausgewählt. Das Zertifikat zeigt auch das neue Ablaufdatum an. Dann lief das Zertifikat problemlos 2 Wochen. Es hat alles funktioniert, Outlook, OWA, Login EAC, Shell. Aber nun ist es nun dieses Wochenende schon das 2. Mal, das Outlook, OWA, EAC, Shell nicht mehr geht. Beim ersten Mal habe ich noch die cert-Dateien im "Lokalen Computer" installiert. Dort bei den CA-Zertifikaten wird das Zertifikat auch angezeigt, Laufzeit bis 2046. IIS neu gestartet, dann lief es wieder. Nun jetzt aber wieder nicht mehr. Nachdem Exchange die ganze Woche läuft, muß es ja passen. Aber am WE passiert irgendetwas. Hat jemand einen Tipp, woran das liegen kann? Vielen Dank, Grüße Christoph

So gesehen - ja, PDF ist keine Druckersprache mehr, sondern schon eine ausgewachsene Sandbox

"Stack" zeigt Dir die DLLs an, die der Prozess geladen hat. Da sollte irgendwas dabei sein, was nicht zu Windows gehört Bei mir taucht da z.B so ne lustige E_YLMBOBE.DLL auf, die von Seiko Epson ist - kein Wunder, ist auch ein Epson-Drucker hier... (Anzeige ist etwas b***d, Symbols sind nicht konfiguriert, aber sollte verständlich sein)

Creator-Owner ist wer?

Nice!

doch mit PDFs kann man einiges anstellen .. hab erst kürzlich gelesen, dass da einer ein eigenes Linux in ein PDF zum Laufen gebracht hat ... https://www.heise.de/news/Linux-laeuft-im-PDF-10272022.html

Jetzt ist der Exchange SE "so halb" in den Product Terms aufgetaucht. Von einer erforderlichen SA / Subscription steht noch nichts da: Microsoft Product Terms Beim Share Point SE ist bspw. dieser Satz zu finden (Microsoft Product Terms): Mal schauen, wie lange es bis zum Update für die Exchange Terms braucht.

Wenn du über die Verbindung nichts zur Verfügung stellst, dann sollte das kein Thema sein. Da die Zugangsdaten des Zielservers auch nicht in der PAW funktionieren, ist der Rückweg auch nicht möglich. VG, Jan