NorbertFe

Ach hör doch auf Natürlich auch die brauchen mal Feierabend.

Ja, aber ich ging dabei davon aus, dass üblicherweise eine Arbeitszeit von 8h in Deutschland gilt. ;) Ansonsten hast du natürlich Recht. Aber auch von 2012 aus ist es im Allgemeinen "eher unkritisch". Oder an welcher STelle ist dir das mal auf die Füße gefallen.

Dann musst du es manuell aktivieren: https://microsoft.github.io/CSS-Exchange/Security/ExchangeExtendedProtectionManagement/ Hätte dir das HealthCheckerscript auch verraten.

Wenn du Exchange 2019 mit CU14 betreibst, wurde es normalerweise selbständig aktiviert. Wenn du nachschauen willst: https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/ ADFS hat da auch ein paar Probleme, soweit ich mich erinnere. Muss mal nachschauen. edit: Ja korrekt mein Group Managed Service Account für die ADFS Farm hat auch die erwähnte Gruppenmitgliedschaft. ;)

Das wird in den wenigstens Fällen sinnvoll funktionieren, wenn man nicht vorher schon eine saubere Admin Trennung umgesetzt hat. 1. Unkritisch 2. "normalerweise" unkritisch in der Umsetzung und aus Security Gründen definitiv schnellstmöglich umzusetzen. Und zwar nicht nur auf den Domänencontrollern, sondern auf ALLEN Systemen (Client, Member, DC und Drucker usw.) 3. Wenn Exchange mit Extended Protection im Einsatz sein sollte, dürfte sowieso kein LM mehr eingesetzt werden, so dass man das im Allgemeinen heutzutage problemlos auf 3 oder 4 konfigurieren kann. 4. Ja aktivieren. Jedes moderne System ab Vista kommt damit klar. Alle anderen Systeme auch, wenn sie nicht total veraltete Varianten nutzen. Aber das merkst du dann schon ;) 5. Siehe oben. 6. Ja kannst du mit entsprechender Vorlaufzeit (innerhalb von 8h problemlos _2x_ ändern. 7. WEnn man nicht ganz viele LDAP Abfragen stellt die bestimmte sonst nicht lesbare Attribute benötigen, kann man das relativ easy abschalten. Ich lass mich aber gern belehren. 8. Kann man "relativ" unkritisch auf die modernen Varianten umstellen/einschränken. Bye Norbert

Wenn’s nicht eine der beiden default policies ist, dann hilft der Befehl aber auch nix. Oder meinst du den Hinweis einfach ein neues gpo anzulegen?

Macht man heute so, wenn man KI Eingaben gewöhnt ist ;)

Nein, der steht da nur, wenn das System ursprünglich mal FRS lief. Bei neu installierten Systemen die nie FRS haben, ist es immer direkt sysvol (ohne _dfrs).

Ja.

Es gibt wirklich Leute, die sich sowas als Video antun? Viel Gelaber und die wichtigsten Dinge kommen am Ende oder gar nicht vor? ;) scnr norbert

Wenn du händisch die recipient Details im Sync anpasst, sollte man schon genau wissen was und wann und warum man das tut. Da jetzt den genauen Grund rauszufinden wird im Forum schwierig. Das hätte man aber bereinigen können und jetzt nicht so einen Zustand. ;)

was für Änderungen denn, und mit welchem Ziel? Nach den Änderungen oder wie? Warum hast du das Postfach nicht einfach migriert?

Naja dann ändert sich ja nichts. Wenn es weg sein sollte ab 1.7. kostet jede andere Lösung Geld. Ich schau ja auch nicht soviel fern, aber nur die öffentlichen wär mir dann doch zu (ach lassen wir das). ;)

Aber da nehmen sie keine neuen Kunden mehr auf. https://www.heise.de/news/Auslaufmodell-Microsoft-Cloud-Deutschland-4152650.html Und das was aktuell angeboten wird ist am Ende dasselbe als würde man es direkt bei ms beziehen. Man möge mich bitte ggf. korrigieren.

Und google bringt dazu keine Vorschläge? https://stackoverflow.com/questions/313622/powershell-script-to-change-service-account

Mit Outlook oder Exchange Online und dann per Hybrid wieder nach On-Prem verschieben. OK ist weder schnell noch einfach, aber naja. Exchange selbst hat keine IMAP Importer (Exchange On-Prem. ExO hat das). Du könntest entsprechende Tools verwenden wie bspw.: https://www.codetwo.com/exchange-migration/

Ja, ich wußte, dass dieses Argument kommt. Aber eine eigene AD Struktur wird sich ein normaler "mittelgroßer" Betrieb selten leisten (hab ich bisher nicht gesehen afair) und ohne AD ist bspw. der Betrieb eines Hyper-V Clusters nicht so richtig "praktikabel". Und ja, ich weiß dass es bei ESX und Konsorten auch ohne AD geht. ;)

Im Idealfall arbeitet man NICHT mit der Default Policy. Also leg eine neue an. Dann hast du zwei Adressrichtlinien. Für einen user kann aber immer nur eine gelten. Also first match. Die Default Policy ist _immer_ last match (alles was keine andere Richtlinie trifft, übernimmt sie). Nur wenn du in deine neue Policy beide reinschreiben würdest. Das ist aber Blödsinn, weil bestehende Nutzer nur die neue hinzugefügt bekommen (die alte Adresse bleibt bestehen) und neue Nutzer sollen ja wohl nicht mehr die alten Adressen erhalten. Das definierst du in der Adressrichtlinie. Und außerdem solltest du prüfen, ob es Nutzer gibt, bei denen die automatische Adressvergabe deaktiviert wurde. Bye Norbert

Natürlich. Sie gibt dir vor, dass "die für die Administration genutzten Accounts abzusichern sind". Der lokale Account wird mit einem Passwort versehen, dass niemand kennt und im Safe verwahrt und gut ist. LAPS wäre für den Hyper-V Host keine so gute Idee, weil du ohne DC nicht an das Kennwort kämest und dann per Offline Boot das lokale Adminkennwort zurücksetzen müsstest. Kann man zwar machen, ist aber eben im Fall der Fälle erstens stressig und zweitens dauert es auch Zeit, die man ggf. für andere Sachen besser nutzen könnte. Du denkst schon wieder falsch imho.

Du denkst "zuviel" an der Stelle. ;) Die wär ja IMMER möglich mit dem lokalen Admin (denn der hat ja kein MFA).

Na und? Schon, oder wo siehst du Probleme? Mal von den Anforderungen deiner Versicherung abgesehen, die dir das ja mehr oder weniger jetzt "befiehlt" ;)

Wäre ja die Frage, warum man die nicht einfach in die Domäne steckt. Es sei denn es gibt irgendwelche organisatorischen Gründe die dagegen sprechen. Am Ende hast du auf jedem Server (mal vom DC abgesehen) lokale Konten. Es gibt halt immer nen "Glass break Account", der am Ende irgendwie genutzt werden können muss, auch wenn die MFA Lösung grad kaputt ist.

Hast du es denn inzwischen als SET konfiguriert? Falls nein, dann leb halt damit, wenn du den Fehler nicht ausschließen willst.

Nur wenn er ein lokales bereits auf dem PC liegen hat. Ansonsten weiß er ja nicht, dass es mal ein servergespeichertes Profil gab. ;)

Kommt darauf an, ob er sich dann an einem Gerät anmeldet, an dem er schon ein Profil (lokal) liegen hat. Falls ja, wird das einfach genutzt. Kann sein, dass man evtl. Manuell einmal von servergespeichert auf lokal am pc umkonfigurieren muss.