NorbertFe

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.

aber das tun sie mit voller Begeisterung. ;)

Warum nicht? Du willst kein ExO (deine Aussage) und dann kommst du mit Angeboten von Resellern, die dir aber auch nur ExO mit Aufpreis verkaufen. Da ist nichts anders als wenn du es direkt bei MS beziehst. Wenn du also nicht darüber diskutieren möchtest, wirds schwer. Denn ExO ist nun mal der leistungstechnische und preisliche Maßstab. Du kannst also teurer und schlechter einkaufen, aber jeder wird dich fragen: Warum? Es kann ja sein, dass du ExO nicht wirklich magst (kann man dir auch nicht verdenken), aber dann begründe das doch bitte nicht mit Kosten, die in dem Fall sehr wahrscheinlich bei allen "Exchange Hostern/Resellern" höher sein werden.

Rein Interessehalber, welche Funktionen "wollt" ihr denn nicht? Ich meine die Kosten mit 3,70€ pro Benutzer und Monat dürften sich nicht so sehr von den anderen Anbietern unterscheiden (ich laß mich aber gern korrigieren).

Du bist die absolute Ausnahme und außerdem eben nicht der „normale“ Kunde. :p ja es gibt einige wir euch, aber auch dann seid ihr eben nicht der Normalfall.

Siehst, war doch ganz einfach.

Ja, und da hast du dann einfach aufgehört zu antworten. Was erwartest du? ;)

Kann ich das, oder muss das ein Admin/mod tun?

Hi, gerade gelesen: https://heise.de/-9752366 Wer sie bisher genutzt hat, sollte sie also aus seiner Konfiguration rausnehmen. Wer weiß, wem die in Zukunft gehört. :) Bye Norbert

Ich weiß, dass das per Powershell geht. :/ Und warum geht es und warum heißt der Schalter so wie er heißt? Weil man den Kram halt für Installationen wie deine bereithalten wollte/musste. Nutze SET, das ist sinnvoller in fast allen Fällen, die ich so kenne.

Seit Server 2022 ist das in der gui gar nicht mehr möglich einen virtuellen Switch an ein lbfo Team zu hängen. Nutze stattdessen das Switch embedded teaming.

Alternativ legt man eine neue db an und verschiebt die Mailboxen alle da hinein und löscht hinterher die alte Datenbank. Was ist das denn?