NilsK

-

Moin, naja ... alles, was wir darüber wissen, ist: Der TO hat nicht behauptet, dass der Tester eingefordert habe, das mal eben so abzuschalten. Und mal ehrlich: Wenn ein externer Pentester auf so einen Befund nicht hinweisen würde, wäre es nicht okay. Er ist schließlich Pentester und nicht Exchange-Dienstleister. Also, wo liegt jetzt das Problem? Und woher nehmen wir hier die Gewissheit, dass der Tester nicht gut arbeite? Gruß, Nils

Moin, dann hätte der kein Kennwort gehabt. Oder halt das, was du vorher vergeben hattest. Gruß, Nils

Moin, ja, das trifft zu. Gruß, Nils

Moin, dein Netzwerk bildet nach AD-Logik einen einzigen Standort, weil ein AD-Standort nun mal über eindeutige Subnets definiert ist. Ein Standort kann mehrere Subnets haben, aber jedes Subnet darf nur an einem Standort auftauchen. Wenn "Glasfaser" bedeutet, dass beide Standorte mit LAN-Qualität verbunden sind, dann ist das auch okay. In dem Fall gibt es ja (vermutlich) keine Bedarf, den Zugriff auf die DCs zu steuern. Möchte man das hingegen kontrollieren, dann müsste man die Standorte AD-logisch trennen, d.h. die Subnets eindeutig machen. Gruß, Nils

Moin, supported ist es auch mit Exchange 2019, die Server als VMs laufen zu lassen. Die "Preferred Architecture", die Hardware empfiehlt, gab es schon bei Exchange 2013, und ab 2016 gilt sie als bevorzugt gegenüber VMs. Das liegt einfach daran, dass Microsoft mit Exchange auf die richtig großen Datacenter zielt. Und da haben die eingebauten Storage-Funktionen ihren Sinn, den sie aber nur mit Hardware ausspielen können. Braucht man das nicht, dann läuft es auch prima als VM. Und ebenso prima mit weniger als 128 GB RAM. Aber wir wiederholen uns ... Gruß, Nils

Moin, in deiner Situation kannst du die Standorte nicht im AD abbilden. Beide Lokationen bilden aus AD-Sicht einen einzigen Standort, weil die Netzwerke das so vorgeben. Gruß, Nils

Moin, hätte man bei dem Betreff aber drauf kommen können, oder? SCNR, Nils

Moin, ich kann die Empfehlung nachvollziehen. Nach allem, was ich höre, würde ich gerade in einer kleinen IT momentan konservativ vorgehen. Das heißt nicht, dass es mit 2019 zum Scheitern verurteilt wäre. Es gibt aber - leider - immer noch das eine oder andere Fragezeichen dort. Gruß, Nils

Moin, sorry, aber wirklich: Stammtisch, und zwar ziemlich fortgeschrittener Zeitpunkt. Was auch immer da beim TO nicht richtig läuft - das ist so weder üblich noch vom Hersteller vorgesehen. Kein Grund, irgendwelche völlig überzogenen Schlüsse und Bewertungen daraus abzuleiten. Gruß, Nils

Moin, eine Anwendung muss dafür eingerichtet sein, mit einem MSA zu arbeiten. Wenn sie nur ein "klassisches" Konto vorsieht, ist sie i.d.R. ungeeignet. Gruß, Nils

Moin du erzeugst zwei Gruppen. In eine (A) kommt der Rechner der Ober-OU, in die andere (B) die Rechner der Unter-OU. Dann erzeugst du zwei GPOs. Die eine (alpha) regelt, was für den/die Rechner der Gruppe A gelten soll. Die andere (beta) regelt, was für die Rechner der Gruppe B gelten soll. GPO alpha koppelst du an die Ober-OU und stellst in den Sicherheitseinstellungen der GPO alpha ein, dass sie nur für die Gruppe A übernommen werden soll. GPO beta koppelst du an die Unter-OU und stellst in den Sicherheitseinstellungen der GPO beta ein, dass sie nur für die Gruppe B übernommen werden soll. Das testest du zunächst in einer separaten Laborumgebung. Wenn es da fertig entwickelt und getestet ist, überträgst du es in die Produktion. Gruß, Nils

Moin, alles Nötige wurde in diesem Thread genannt. Gruß, Nils

Moin, also geht es eigentlich um die Installation von Exchange 2019? Dann ist ja der Betreff etwas irreführend. Es hilft, wenn du uns eine konkrete Idee gibst, was du denn eigentlich vorhast. Zum UCMA hatte ich mir kurz vor Release mal notiert: "nicht das aus dem Web nehmen, sondern von der DVD unter UCMARedist". Außerdem musste man damals die VC++-Runtime installieren: https://www.microsoft.com/en-in/download/details.aspx?id=40784 Hab es seither nicht mehr angefasst. Gruß, Nils

Moin, ja, das haben die betreffenden Kunden auch gedacht. Kostet dann halt empfindlich fünfstellig, so ein Irrtum. Zum Beispiel "corp.tld" oder "domain.tld" - halt abstrakt. Man kann auch eine "sinnlose" Buchstabenkombination nehmen. Ein Kunde hat sich mal für ein Standortkürzel entschieden, ohne Firmenname. Das Kürzel ist aber abstrakt genug, damit es bei einem Standortwechsel kein Problem darstellt. Wichtig ist dann, dass einem die Domain gehört, was sich leicht bewerkstelligen lässt. Da man mit der nicht nach draußen auftritt, muss man auch nicht besonders auf das Markenrecht achten. Gruß, Nils

Moin, also, mal ehrlich: Ich finde nicht, dass das "halt so" ist. Windows 2003 erhält seit bald vier Jahren keine Updates mehr. Noch dazu war die Domäne des TO auf dem Stand von VOR Windows 2000. Wer eine IT-Umgebung so betreibt, handelt nicht nur grob fahrlässig, sondern gefährdet aktiv andere. Wir reden ja nicht von Insel-IT, sondern in aller Regel von Netzwerken mit Verbindungen nach außen. Mag sein, dass der TO dafür nicht direkt verantwortlich ist, aber irgendwo muss mit dem Verständnis auch mal Schluss sein. Gruß, Nils

Moin, absolut. Wenn es aber um einen neuen Domänennamen geht wie hier, ist es aus meiner Sicht sehr schlau, dieses "Müssen" einfach durch einen abstrakten Domänennamen von vornherein auszuschließen. Lustigerweise neigen die genannten Kunden dazu, meiner Argumentation zuzustimmen, dass das Wechseln des Firmennamens für das AD völlig unangemessener Aufwand ist. Dann machen sie es doch und nehmen als neuen AD-Namen den neuen Firmennamen ... Gruß, Nils

Moin, das ist eine Sache der Abwägung. Ich würde mittlerweile nie mehr den Namen des AD an den Namen des Unternehmens anlehnen. Dafür habe ich zu viele Kunden, die nach einer Umfirmierung ihr AD migrieren müssen, nur um den Namen zu ändern. Gruß, Nils

Moin, die Übersetzung mag etwas schräg sein, aber die Darstellung von testperson ist trotzdem richtig. Zehn Konten mit jeweils beliebig vielen Offline-Anmeldungen. Maximal zu erhöhen auf 50 Konten. Gruß, Nils

Moin, naja, aber dann weißt du ja, wo dein Problem liegt. Bluescreens sind immer Treiber- oder Hardwareprobleme ... Gruß, Nils

Moin, also, ob ich mein AD einem Billigrechner anvertrauen würde ... aber in jedem Fall ist ein separater physischer DC immer eine gute Idee. Gruß, Nils

Moin, ja, das meine ich. Wenn du nur den Systemstate sicherst, kannst du den in einem laufenden Windows wiederherstellen. Ist also eine Frage der Szenarien. Ein Backup ist nur die weniger interessante Hälfte, wichtig ist das Recovery-Konzept, das die wichtigen Szenarien zur Wiederherstellung umfassen muss. [Video-Tutorial: Active Directory Object Recovery | faq-o-matic.net] https://www.faq-o-matic.net/2009/09/07/video-tutorial-active-directory-object-recovery/ Gruß, Nils

Moin, naja, was erwartest du denn? Es gibt in großem Stil kostenlose Testsoftware und kostenlose Azure-Nutzung. Wenn man sowas dauerhaft braucht, dann steckt wohl ein kommerzielles Interesse dahinter. Rein von der Logik her finde ich es absolut legitim, dass der Hersteller damit dann Geld verdienen will. Edit: Und was den "Trick" mit dem Action Pack angeht: Wie XP-Fan schon richtig anmerkt, ist das ein Programm, das sich an Unternehmen wendet. Microsoft gewährt die Vorteile, weil es die Gegenleistung erwartet, dass der Partner Geschäft mit Microsoft-Produkten macht. Es ist keine billige Möglichkeit für "daheim" - faktisch wäre das ein Verstoß gegen die Grundbedingungen, also i.W. dasselbe wie eine Raubkopie. Gruß, Nils

Moin, warum Admins bei sowas immer mit "paranoid" kommen, wird sich mir nicht mehr erschließen ... Ergänzend empfehle ich, ein regelmäßiges AD-Backup mit Bordmitteln herzustellen, also den Systemstate täglich mit Windows Server Backup zu sichern. Beim AD sollte man immer einen doppelten Boden haben (zwei Sicherungsmethoden parallel). Das Systemstate-Backup mit WSB ist die einzige Sicherung, die von Microsoft komplett unterstützt wird. Diese Option sollte man nutzen, zumal sie kaum Aufwand erzeugt. Gruß, Nils

Moin, aber ihr sichert euer AD doch hoffentlich täglich? Gruß, Nils