NorbertFe

Na wenns weiter nix is. :)

Hat ja niemand gesagt, dass deine zentrale Technik für den Vorschlag derzeit pauschal geeignet ist. ;) Wird halt beliebig komplex und am Ende sollen tatsächlich noch Menschen mit den Systemen arbeiten und im Idealfall sogar sinnvolle Ergebnisse produzieren.

Damit im Fehlerfall beides weg ist? :) Wie schon angesprochen, sollte man das auf die Daten auf mehrere DBs _und_ Volumes verteilen. Und? Dann leg halt ne neue VHDX an mit 800GB-1TB und zieh die Daten dahin um.

Eure ExchangeDB ist größer 2TB? Ich würde da eher eine neue VHDX anlegen und die Postfächer dann in eine neue DB verschieben. Geht ohne Downtime für die Nutzer.

Und warum ist das nicht möglich? Man kauft die Basis Lizenz = 16 Cores und schon ist das möglich. Ja klar. nein müssen musst du nicht.

Man kann auch einfach den Dienst anhalten. Die Dateien löschen und die db wieder Minuten. ;) geht schneller

Was stört dich denn an einer leeren Datenbank?

Welche Doku liest du denn? Aus dem Jahr 2003? Die Reiter gibts seit 2007 nicht mehr. ein Nutzer kann nur ein Postfach haben. Du kannst einen zweiten Nutzer (oder Shared Mailbox) anlegen und dem ersten Nutzer Vollzugriff darauf geben. damit sparst du dir die Ordnerberechtigungen ;)

Ja stimmt, da schau ich bei Problemen auch nie rein. :p zu den Events gibts aber genug zu lesen.

Wie wäre es mit einem Blick in die entsprechenden eventlogs?

Worüber reden wir dann hier? Wie schon gesagt: du hast ein anderes Problem und hättest sonst die 2019er nicht als dc hinzufügen können.

Wäre jetzt erstmal die Frage, wie der STatus auf dem "alten" DC ist. Ist dort DFS-R oder NTFRS fürs Sysvol zuständig? Im Zweifel fängt man nochmal von vorn an und entfern die DCs 2019 nochmal und migriert zu dfsr und fügt sie dann wieder hinzu. Für alles andere sind das hier ein paar zu wenig Infos.

Zum dritten Mal.

Wie kommt der Termin eigentlich da ins Ressourcenpostfach? Wird das normal eingeladen, oder wird das händisch dort angelegt?

gpmc.msc :)

Ja red nur nicht mit uns. Ist ja dein Problem.

Du brauchst ein Zertifikat welches NUR auf den dyndns Namen zeigt und mußt deinem Exchange beibringen, dass alle virtuellen Verzeichnisse auf diesen dyndns-Namen zeigen müssen. Dein anderes Zertifikat ist für die Tonne. Damit Autodiscover von extern funktioniert, mußt du einen http redirect konfigurieren, was schwierig wird, wenn du nicht noch einen weiteren Webserver im Internet hast, der dann _nur_ auf http hören darf.

Hat Nils dir doch geschrieben. Die dll ist Bestandteil der Printerrolle. Und die auf einem DC zu installieren ist sowieso schon "suboptimal". Und ja, egal was man sagt, die Leute meinen es immer besser zu wissen, weil es bei Ihnen bisher läuft. Alle anderen die andere Erfahrungen gemacht haben, erzählen nur was vom Pferd. :)

Aaaaaaahhhh mit der ekligsten Methode von allen? Mach das weg.

Und was soll der mx dir bringen? Wie gesagt, ein bisschen Grundlagen von DNS sollte man schon mitbringen, wenn man Geräte ins Internet stellt.

Hol dir doch das Calendarprocessing doch mal per powershell und setz es hier rein. BEkommt der Nutzer denn eine "Bestätigung" über die Raumbuchung?

wahrscheinlich beides. Wie ist denn die Ressourcenautomatik des Raumes konfiguriert?

Ein Zertifikat auf deinen dyndns Namen. Hab ich aber oben schon geschrieben. Also liest du sehr selektiv. ;) Du kannst von aussen nicht sinnvoll mit deiner eigenen Domain hantieren, Ausser du bekommst den Dyndns Namen und deine eigene Domain (Hostnamen) in ein Zertifikat. einen mx? Oder einen c-name? So oder so hilft dir das nicht, weil du per https deine Domain ansprichst und dann auf den dyndns Namen umgeleitet wirst, was einen Fehler im Browser erzeugen wird.

in einem Docx lassen sich meines Wissens nach nicht so ohne Weiteres Makros verstecken. Dass das natürlich wieder nur ein kleiner Baustein im Gesamtkonstrukt darstellt ist klar. (Wir schweifen etwas ab). :)

Und .doc Dateien sollte man heutzutage gar nicht mehr verwenden. Gibt ja erst seit ca. 15 Jahren docx. ;)