NorbertFe

Beste Voraussetzungen also. 😆 welche wr nimmst du?

Und wieso zwei WR? Verschiedene Wände?

Vermutlich wärst du selbst drauf gekommen. ;)

So langsam gehts mir trotzdem auf die Nerven: Ja, man muss dann nur noch den Sync auf Cloud-Sync umstellen, damit man all die neuen Features nutzen kann. Ich bezweifle, dass es wirklich technische Gründe gibt, das nicht auch in Entra Connect zu implementieren, abgesehen davon, dass man Entra Connect insgesamt eigentlich gar nicht mehr haben möchte.

Mag sein, nur ist der Exchange nicht der Grund für das Zertifikat auf dem dc.

Exchange funktioniert problemlos ohne Zertifikate auf den dcs.

Und hyper-v Hosts mit laps sind auch ein Stolperstein, wenn mal die komplette Umgebung down sein sollte. Und ja alles schon erlebt. Utilman.exe hilft zwar, dauert aber alles in solche Situationen. ;) seitdem sind die hyper-v Hosts bei den Kunden meist ohne laps konfiguriert und haben einfach komplexe lange Kennwörter, die man ja nie eingeben muss, solange die Dinger im ad hängen.

Dann nimm halt esx ;) alternativ bau halt nicht nur zwei luns sondern mehrere. Dann hast du zwar das gleiche Problem, kannst aber notfalls einen Teil der Maschinen einfach umhängen. Auf Kosten der Flexibilität im Storage natürlich. Es bedient sich imho bescheiden. auch wenn ich das Bedürfnis verstehe, den Cluster nicht ins produktive AD zu hängen, wäre das für mich immer noch kein wirklicher Grund es nicht trotzdem zu tun. Erst recht nicht, wenn der workload einzig und allein die Umgebung des AD und seinen Mitgliedern beinhaltet. Wenn dein ad kaputt is sind die hyper-v Hosts das geringste Problem und wenn die hyper-v Hosts die Ursache für die Übernahme waren, dann gabs sowieso ein Problem an anderer Stelle. Anders sieht es aus, wenn da noch weitere unabhängige Systeme drauf laufen.

bei hyper-v reichen zwei. Theoretisch sogar einer, aber das wär ja ziemlich sinnfrei hinsichtlich der Verfügbarkeit. ;) Man muss mit den Einschränkungen leben, die der Cluster ohne ad hat. zu Deiner ursprünglichen Frage: Ja Du kannst auch zwei Hosts auf ein Storage zugreifen lassen, ohne clusterkonfiguration. Musst nur sicherstellen, dass das zoning stimmt. Nur ein host darf seine eigene lun sehen (und schreiben).

Da liegen schon ein paar wenige Sachen mehr als deine logonscripte. Zum Beispiel die default Policies. Nix, was man nicht reparieren kann, aber wenn du da schon seit Monaten kein Ergebnis bekommst, was erwartest du jetzt? ;) technisch ist das, wie hier schon mehrfach angedeutet, nicht besonders schwer.

Nabend, na der Großteil scheint diesmal irgendwie im transportmodul zu liegen. Alles irgendwelche smtp spoofings, wenn ich das am Handy richtig gelesen habe.

Die beschreiben doch alle dasselbe. Wo isn dein Verständnisproblem? Der Link den du gepostet hast ist der von April (da war das das Vorgehen und ist es immer noch, nur war da Exchange SE natürlich noch nicht veröffentlicht). Der den ich gepostet habe ist von vorgestern und natürlich beschreibt der dasselbe Vorgehen, nur eben ein wenig ausführlicher in seinen Erklärungen.

Ich glaub ich rede chinesisch. Der Healthchecker gibt dir einen schönen Link, den solltest du komplett lesen, verinnerlichen und dann entsprechend abarbeiten. ;) https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/ Alternativ lies das hier: https://techcommunity.microsoft.com/blog/exchange/dedicated-hybrid-app-temporary-enforcements-new-hcw-and-possible-hybrid-function/4440682 Wichtig der Abschnitt: What you should do

SE beinhaltet den April Patch. Tätig werden musst du trotzdem, falls du eine Exchange Hybridbereitstellung nutzt. Wenn du keine Exchange Hybridbereitstellung nutzt, ist es egal ob du den Patch drauf hast oder nicht und auch unter SE musst du dann nichts tun. ;)

Wie schön wär die Welt ohne User-Postfächer :)

Ja so in etwa. Irgendwann migrieren vermutlich alle frustriert zu Postfix. ;)

Da hat vermutlich jeder andere Vorstellungen. Einige Wünsche gabs ja schon irgendwo im EHLO Blog bei MS in den Kommentaren. Nachdem jetzt modern Auth möglich ist für EAS und MAPI fehlt mir "vorerst" mal nur TLS 1.3 für SMTP und ein DKIM signer. Aber insgesamt hat MS halt ihr eigenes On-Prem Ökosystem inzwischen schön ausradiert.

Ich glaub, wenn die nicht auch noch technisch in das On-Prem Produkt investieren, sind die 10 Jahre schon sehr großzügig, weil die Kunden dann früher oder später zu Alternativen wechseln werden. Und aktuell siehts ja nicht so aus, als wenn da irgendwelche Innovationen On-Prem zu erwarten wären.

Hab ich auch mal gemacht, aber nur, weil der Kunde zu Exchange 2003 sollte. Und den ADC gabs nur für Exchange 5.5. Aber von 5.0 auf 5.5 ging ja so wie heute per Inplace ;) Sowas hab ich auch 2004 oder so gesehen. War keine Hochschule, sondern in der Wirtschaft kombiniert mit einem komischen Domänenkonstrukt und eDirectory ;)

Ja, aber da hieß es MSMail ;) Wenn man das als Vorläufer bezeichnen mag. Wobei ich keinen persönlich kenne (glaube ich jedenfalls), der vor Exchange 5.0 schon mit MS Mailprodukten zu tun hatte.

Die Meldung kommt jedenfalls nicht von den exchange eigenen Transport Agents. WEnn Avast raus ist (disable-transportagent) einfach mal testen. Im Logfile des Exchange Servers muss das dann aber eben auch auftauchen.

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

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

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.