Alle Aktivitäten

Nein, bestimmt nicht…

Danke, Norbert, für die ausführlichen Infos. Dank dir und den Links habe ich heute viel neues dazu gelernt. jetzt lese ich mir erst mal alles nochmal genau durch. Einen schönen Tag wünsche ich dir

Ja und nur bei diesem Zertifikat/VDir. Dem selfsigned Zertifikat werden SMTP und die Backendseite zugeordnet (für SMTP ist das das DEFAULT Zertifikat, man beantwortet die Frage also mit Ja) Dem externen Zertifikat kannst du SMTP, http und imap und pop zuweisen. Für SMTP ist es NUR dann zuständig, wenn im Empfangs-/Sendeconnector auch ein Name im HELO String steht, der im Zertifikat auftaucht. Also NICHT im Defaultconnector. Die Frage bei der SMTP Zuweisung beantwortet man also in dem Fall mit NEIN (außer man weiß sehr genau was man tut und warum). Egal, was einfacher für dich ist. IMAP ist für den Empfang nicht für den Versand. Welches Zertifikat du nutzt hängt davon ab, welchen Namen du im CRM System hinterlegt hast (lokaler Exchange oder der Name des externen Zertifikats) und ob dein CRM das ggf. akzeptiert, wenn es dem Zertifikat nicht vertraut. IMAP und SMTP laufen weder über Default noch Backend-Webseite, weil es keine Web-Protokolle sind. ;) Bye Norbert

da hast natürlich recht, das ist schon ein Unterschied. Also, wenn ich das per Powershell anlege, kann ich hinterher ins IIS gehen und dort dem Back End bei Bindungen zuweisen? ich habe das nun per Powershell angelegt. Ja, hier sind es 5 Jahre. Nun noch 3 Fragen bitte, dann kann ich mal damit arbeiten: 1) Welche Dienste müssen/sollten dem self-signed Zertifikat und dem externen Zertifikat zugewiesen werden? 2) Die Zuweisung der Dienste dann per EAC oder Powershell? 3) Wir haben ein CRM-System, mit dem man per IMAP eMails schicken kann. Da ist natürlich der Exchange als IMAP/SMTP-Server eingetragen. Welches Zertifikat ist hierfür verantwortlich (self-signed oder das externe), und läuft das über Default Web Site oder Back End und es sind hier für die Dienste IMAP/SMTP notwendig? Ich danke dir für deine Zeit und Expertise

Deswegen hab ich dir ja auch den Powershellbefehl hingeschrieben und gesagt machs per Powershell weils logischer ist als diese Klickorgie. ;)

ich habe das self-signed Zertifikat 1:1 nach dieser Anleitung gemacht: https://www.frankysweb.de/exchange-2016-backend-zertifikat-neu-erstellen/ und Frankysweb ist ja auch vertrauenswürdig. wenn ich das per EAC mache, wird noch folgendes gefragt: und Was ist denn hier auszuwählen? Aus der Anleitung von MS zum Erstellen von self-signed Zertifikate werde ich da nicht ganz schlau draus bzw. möchte nicht, dass das mit dem externen Zertifikat kollidiert.

Keine Ahnung, was du da gemacht hast, aber ich hab das jetzt grad getestet und ein selfsigned Zertifikat hat 5 Jahre Laufzeit: Das war jetzt einfach mal per EAC, was ich sonst nie verwende. Mit new-exchangecertificate -privatekeyexportable $true -IncludeServerFQDN -IncludeServerNetBIOSName new-exchangecertificate -privatekeyexportable $true -IncludeServerFQDN -IncludeServerNetBIOSName Sollte ein passendes Zertifikat rauskommen und 5 Jahre Laufzeit haben. Wenn das bei dir anders ist, dann ist was schief.

Ich danke dir. Ich lese natürlich immer erst einige Seiten, teilweise auch bei MS, bevor ich in einem Forum schreibe.

Quark, das hat MS alles mundgerecht auf der Webseite. Man muss nur mal nachschauen: https://learn.microsoft.com/en-us/exchange/architecture/client-access/import-certificates

Ja, wenn man immer mehr mit dem Exchange Powershell arbeitet, wird das natürlich immer vertrauter. Ich mache da immer öfters was. Gute Frage, wo das Zertifikat für Back End ist. Keines vorhanden. Die letzten Wochen/Monate wurde da nichts gemacht, und es lief ja immer. In die Bindungen vom Back End hatte ich noch nie geschaut. Ich habe nun mit der Anleitung von https://www.frankysweb.de/erneuern-des-zertifikats-fur-das-exchange-server-back-end/ ein neues self-signed Zertifikat erstellt und ans Back end gebunden. Scheint aber nun nur noch 1 Jahr Laufzeit zu haben

Ja kannst du, aber ich würde immer die Exchange Powershell nehmen. Ist deutlich logischer in meinen Augen. Jeder Exchange hat doch per Default ein selfsigned Zertifikat. Wo ist denn deins hin? Einfach Zertifikate zu löschen ist keine gute Idee, wenn man nicht genau weiß wofür und wo es benutzt wird. Das Backend Zertifikat ist eine der wenigen Ausnahmen, welche man tatsächlich auch im IIS regeln kann/sollte. Da so ein selfsigned Zertifikat aber eine Laufzeit von 5 Jahren hat und auch keine Probleme bei Ablauf verursacht, muss man da normalerweise NIE ran. ;)

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.