Ab wann zweite Datenbank Exchange 2019
Guten Morgen Zusammen,
wir bekommen neue Kollegen an unserem Standort durch einen Zukauf hinzu.
Derzeit haben wir einen Exchange 2019 Standard mit einer Datenbank im Einsatz. Wir sind derzeit 20 Mitarbeiter.
Durch den Zukauf werden wir hinterher ca. 65 Mitarbeiter sein. Die Postfächer der zugekauften Firma sollen
auf unseren Exchange umziehen. Den Umzug sehe ich erstmal unkritisch. Nur der Exchange macht mir ein bißchen Kopfschmerzen. Die max. Datenbankgröße liegt ja bei 1024. Die neuen Kollegen haben im Schnitt 20GB große Postfächer,
unsere sind alle kleiner 5GB. Die Datenbankgröße ist somit wohl erreicht, selbst wenn die neuen Mitarbeiter Ihre Postfächer noch bereinigen wird es knapp werden. Gibt es hier eine Empfehlung ab wann Ihr eine zweite Datenbank erstellt? (z.B. Datenbankgröße 500GB oder generell ab 30 Mitarbeiter etc.) Oder habt Ihr einen ganz anderen Ansatz?
Viele Grüße
Jobbi
wir bekommen neue Kollegen an unserem Standort durch einen Zukauf hinzu.
Derzeit haben wir einen Exchange 2019 Standard mit einer Datenbank im Einsatz. Wir sind derzeit 20 Mitarbeiter.
Durch den Zukauf werden wir hinterher ca. 65 Mitarbeiter sein. Die Postfächer der zugekauften Firma sollen
auf unseren Exchange umziehen. Den Umzug sehe ich erstmal unkritisch. Nur der Exchange macht mir ein bißchen Kopfschmerzen. Die max. Datenbankgröße liegt ja bei 1024. Die neuen Kollegen haben im Schnitt 20GB große Postfächer,
unsere sind alle kleiner 5GB. Die Datenbankgröße ist somit wohl erreicht, selbst wenn die neuen Mitarbeiter Ihre Postfächer noch bereinigen wird es knapp werden. Gibt es hier eine Empfehlung ab wann Ihr eine zweite Datenbank erstellt? (z.B. Datenbankgröße 500GB oder generell ab 30 Mitarbeiter etc.) Oder habt Ihr einen ganz anderen Ansatz?
Viele Grüße
Jobbi
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5575678750
Url: https://administrator.de/contentid/5575678750
Ausgedruckt am: 25.11.2024 um 09:11 Uhr
10 Kommentare
Neuester Kommentar
Moin,
von MS:
Kurzfassung:
Ohne DAG sind 200GB max pro DB empfohlen, supported max. 16TB
Wie du richtig erkannt hast, kann Exchange Server Standard max. 1TB mounten.
Wir haben z.b. zwei Datenbanken, eine für Nutzer mit Nachnamen von A-M und eine vom N-Z, damit fahren wir ganz gut. Die beiden Datenbanken haben je etwa 150GB. Insgesamt sind es ~150 Postfächer
von MS:
Kurzfassung:
Ohne DAG sind 200GB max pro DB empfohlen, supported max. 16TB
Wie du richtig erkannt hast, kann Exchange Server Standard max. 1TB mounten.
Wir haben z.b. zwei Datenbanken, eine für Nutzer mit Nachnamen von A-M und eine vom N-Z, damit fahren wir ganz gut. Die beiden Datenbanken haben je etwa 150GB. Insgesamt sind es ~150 Postfächer
Moin,
die Userzahl ist ja im Grunde "überschaubar".
Vielleicht nutzt ihr die Gelegenheit und macht euch mit einer Mail-Archivierung vertraut. Wir lagern alles Mails älter 3 Jahre ins MAILSTORE aus. Dadurch bleiben die Postfächer recht klein.
Auch schicken wir nicht mehr zig Anhänge durch die Gegend. Wir legen die auf dem Fileserver ab und versenden nur noch Links dahin.
Sollte das auf massivsten Widerstand stoßen, würde ich auch zwei DBs (A-M und N-Z) vorschlagen. Oder man trennt nach Geschäftsbereichen: Produktion und Administration, oder wie auch immer...
die Userzahl ist ja im Grunde "überschaubar".
Vielleicht nutzt ihr die Gelegenheit und macht euch mit einer Mail-Archivierung vertraut. Wir lagern alles Mails älter 3 Jahre ins MAILSTORE aus. Dadurch bleiben die Postfächer recht klein.
Auch schicken wir nicht mehr zig Anhänge durch die Gegend. Wir legen die auf dem Fileserver ab und versenden nur noch Links dahin.
Sollte das auf massivsten Widerstand stoßen, würde ich auch zwei DBs (A-M und N-Z) vorschlagen. Oder man trennt nach Geschäftsbereichen: Produktion und Administration, oder wie auch immer...
Moin,
Solltet ihr alleine auf Grund der Rechtslange einführen. Gut beschrieben:
https://www.mailstore.com/de/blog/2018/07/25/5-irrtumer-uber-e-mail-arch ...
oder detailiert:
https://www.it-administrator.de/job-weiterbildung/recht/86545.html
Gruß
Doskias
Solltet ihr alleine auf Grund der Rechtslange einführen. Gut beschrieben:
https://www.mailstore.com/de/blog/2018/07/25/5-irrtumer-uber-e-mail-arch ...
oder detailiert:
https://www.it-administrator.de/job-weiterbildung/recht/86545.html
Gruß
Doskias
Zitat von @MysticFoxDE:
Moin @chaot1coz,
wie kommst du den auf diese Idee?
Wir haben einige Kunden, deren DB's auf einem Exchange 2019 Standard, definitiv über 1TB liegen.
Gruss Alex
Moin @chaot1coz,
Wie du richtig erkannt hast, kann Exchange Server Standard max. 1TB mounten.
wie kommst du den auf diese Idee?
Wir haben einige Kunden, deren DB's auf einem Exchange 2019 Standard, definitiv über 1TB liegen.
Gruss Alex
https://learn.microsoft.com/en-us/exchange/troubleshoot/administration/e ...
Dort gibt es auch einen Workaround, aber die offizielle Lösung ist:
In order to have the full functionality of the Exchange database availability group (DAG) again, you must buy an Enterprise Edition license and apply it to the server.
Ich empfehle immer sprechende Namen, und zwar so wie es in deiner Umgebung Sinn macht und für dich und deine Kollegen auf einen Blick erkennbar ist, was die DB nun hostet.
Bei uns heißen die DBs A-M und N-Z
Bei uns heißen die DBs A-M und N-Z
Bei uns heißen sie einfach DB01 und DB02. Bei DBAM und DBNZ wirst du Probleme bekommen, wenn du eine dritte Datenbank hinzunehmen willst/musst. Ob du jemals in diesen Zwang kommst.. Ich persönlich denke eher nicht
Zitat von @chaot1coz:
Ich empfehle immer sprechende Namen, und zwar so wie es in deiner Umgebung Sinn macht und für dich und deine Kollegen auf einen Blick erkennbar ist, was die DB nun hostet.
Das ist der wichtigste Punkt. Technisch ist es egal wie sie heißen, wichtig ist, dass ihr damit zurecht kommt. Bei Namensgebungen ist es immer schwer von außen Tipps zu geben und einen Standard gibt es da auch nicht.Ich empfehle immer sprechende Namen, und zwar so wie es in deiner Umgebung Sinn macht und für dich und deine Kollegen auf einen Blick erkennbar ist, was die DB nun hostet.