NilsK

Moin, wenn es bei der Installation eines der Programme Probleme gibt, dann solltest du die lösen, ggf. gemeinsam mit dessen Hersteller. Ein Betriebssystem-Upgrade hat viele Tücken. Bei einem Client kann das noch gutgehen, selbst da kann es aber problematisch sein. Bei einem Server sind solche Probleme eher zu erwarten, gerade bei einem Terminalserver, auf dem sich ja viel Anwendungssoftware befindet und der vor allem zahlreiche Usersessions ausführt und die zugehörigen Benutzerprofile hat. Daher rate ich nochmals von deinem Vorhaben ab, zumal du ja zwei Upgrades nacheinander machen müsstest. Bei Servern ist generell die Neuinstallation der Königsweg, bei Terminalservern noch mal mehr. Gruß, Nils

Moin, üblicherweise macht man bei Terminalservern keine Upgrades, sondern man richtet sie neu ein und stellt dann die Benutzer um. Gruß, Nils

Moin, ich stimme zu. Den physischen abschalten und dessen Netzwerkports mit Bauschaum ausfüllen. Dann das Computerkonto im AD zurücksetzen und den virtuellen SQL Server erneut aufnehmen. Gruß, Nils

Moin, du musst das Ergebnis hier auch nicht veröffentlichen. Du kannst mit der Auswertung aber prüfen, ob die Subnets vollständig und korrekt zugewiesen sind. Nur so kann dem Client der richtige AD-Standort zugeordnet werden. Wie gesagt, das müsste dann bei allen Domänen passend sein. Zusätzlich müssen in deinem Fall mit den vertrauten Domänen und der Verteilung von Clients und Usern allerdings die Namen der betreffenden Sites in den verschiedenen Domänen bzw. Forests gleich sein, damit die Zuordnung funktioniert - das meinte ich mit den komplexeren Details. [Domain Locator Across a Forest Trust | Ask the Directory Services Team] https://blogs.technet.microsoft.com/askds/2008/09/24/domain-locator-across-a-forest-trust/ Gruß, Nils

Moin, äh - wie Norbert schon andeutet, ist dieser Umstand (zwei Domänen) für die Frage natürlich alles andere als nebensächlich. In deinem Szenario müssten DCs beider Domänen an den Standorten vorhanden sein, an denen sich User anmelden. Und genauso müssten die Subnets auf beiden gepflegt sein. Da die domänenübergreifende Anmeldung noch eine ganze Ecke komplexer sein kann, kann es dabei dann aber durchaus passieren, dass die Anmeldung nicht wie gewünscht verläuft. Das zu analysieren und zu optimieren, wäre dann aber ggf. eine Sache, die man sich im Detail ansehen müsste. Gruß, Nils

Moin, welche Subnets sind denn konkret welchem der Standorte im AD zugewiesen? Du kannst dies mal mit diesem Tool auslesen: [Borg: AD-Standorte dokumentieren | faq-o-matic.net] https://www.faq-o-matic.net/2007/04/28/borg-ad-standorte-dokumentieren/ Jedes Subnet, in dem sich Clients befinden, muss eindeutig einem AD-Standort zugewiesen sein. Nur wenn das stimmt, kann das AD dem Client den passenden Logonserver nennen. Gruß, Nils

Moin, Shared Memory? In Hyper-V? Kann es sein, dass du da was durcheinander bringst? Gruß, Nils

Moin, ja, genau das meine ich. Danke für den Hinweis. Manchmal sollte man mit der Bewertung der Arbeit anderer einfach ein bisschen vorsichtiger sein ... Gruß, Nils

-

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