cj_berlin

Die Frage ist, solltest Du das auch? Deine nächste Aufgabe ist nun, herauszufinden, ob es einen Grund für diese Konfiguration gab, und die jeweiligen Einstellungen zu prüfen. Respektive, wenn es nur eine "wir haben es schon immer so gemacht"-Konfiguration ist, auf SET umbauen. Allerdings wenn Deine VMs ihre NIC-Konfiguration verlieren, solltest Du parallel schauen, welche Event IDs dort zu finden sind.

Hast Du dabei auch die nicht mehr vorhandenen VMware-Netzwerkkarten eingeblendet und gelöscht?

Moin, natürlich wäre ein Edge Server auch eine Art Gateway vor dem Exchange, und da würden Mail Flow-Regeln (a.k.a Transportregeln) unterstützt werden. Aber das vermutlich nicht ganz das, was Du mit der Frage bezweckst, somit ist den Antworten der beiden Norberts wenig hinzuzufügen.

Moin, warum macht man das 2024 noch per CMD?

Moin, ist das Verhalten anders, wenn Du den Server-Manager direkt am Connection Broker startest?

Moin, versuche mal, die ÖO-Mailbox in eine andere Datenbank zu verschieben. Eventuell ist ein Defekt irgendwo in den Daten.

Domain Controller. Fileserver, Datenbankserver und sowas sind nicht Tier 0. In der ursprünglichen Microsoft-Denke wäre das Tier 1, und Clients + Terminalserver sind Tier 2. Du kannst beschließen, nicht päpstlicher zu sein als der Papst und nur den Tier 0 vom Rest zu isolieren.

Wieso denn? Du musst ja nicht 20 Tier bauen, sondern - weil die Umgebung so klein ist - nur einen Eine Policy, die verbietet, dass Tier 0-Accounts sich an Nicht-Tier 0-Maschinen anmelden, ein zweites Admin-Account für jeden der beiden Admins plus das Kennwort für bestehende Accounts rollen, that's it.

Moin, die Idee ist gut, der Gedanke ist aber andersherum und nicht weit genug. Wenn Dein AD gekapert wird, sind Member-Server sowieso dahin. Das beginnt aber in den seltensten Fällen beim AD selbst, meistens ist ein Member-System das Einstiegstor. Das heißt, Deine oberste Prämisse ist es nicht, die Member vor AD zu schützen, but eher die Admins vor den Membern zu schützen. Sprich: Es ist nicht wirklich schlimm, ein AD-Account als lokalen Admin auf den Member-Systemen zu haben, Du willst aber verhindern, dass AD-Admins sich an Membern überhaupt anmelden, egal ob sie dort Adminrechte haben oder nicht. Manche kennen das Konzept als "Tiering".

Moin, im IIS herumfummeln ist bei Exchange fast nie die (nachhaltige) Lösung. Vermutlich wird dies beim Einspielen des nächsten CU wieder wegfliegen. Vielleicht ist es aber auch wirklich etwas, das durch das Windows- und damit IIS-Update versaubeutelt wurde. Markiere diesen Thread für den Abend, an dem Du das nächste CU einspielst

"nimm das Remote-Zert" --> Den Dienst "IIS" in den Eigenschaften des Zertifikats zuweisen. "In allen virtuellen Verzeichnissen blah..." --> Autodiscover URI siehst Du mit Get-ClientAccessServer

Da gibt es diesen "View Certificate..." Button, der Dir die Antwort liefern würde Aber tatsächlich "sucht" Autodiscover kein Zertifikat. Es kontaktiert den Webservice, und dieser präsentiert ein Zertifikat. Die kontaktierte URL siehst Du in der Fehlermeldung. Das Zertifikat hinter dem Button, s.o. Warum es nicht matcht, siehst Du dann.

Doch, wenn Du das interaktiv auf einem DC ausführst, muss das elevated ausgeführt werden.

Zeig doch mal den Code, der diese Ausgabe erzeugt.

Ich weiß nicht ob es das Problem ist, aber in Deinem allerersten Code-Snippet selektierst Du "sKriptPath" anstelle von "sCriptPath". Damit bleibt die Property "scriptPath" immer leer.

96 GB ist 6*16. Früher waren 6 DIMMs per Socket Gang und Gäbe, keine Ahnung wie exotisch das jetzt ist. Es geht ja dabei nicht um die Performance, sondern.um die Minimierung der Auswirkungen bei Ausfall einer Komponente. Und @Scotx: bei all der Virtualisierungsorgie das Backup nicht vergessen 😊

Wenn Du es ohne AD, nur mit Entra ID, lösen kannst, dann brauchst Du auch keine hybride Identität um ihrer selbst Willen.

...oder Du machst es mit der formatierten Ausgabe: $LinkName = 'BlaKeks' 'Es gab einen Fehler beim Anlegen des Links "{0}". Bitte manuell nacharbeiten.' -f $LinkName

Moin, ist die VM denn schon gelaufen und nach welchem Ereignis hat sich der jetzige Zustand eingestellt?

Hi, das sollte nach wie vor funktionieren: https://lizardsystems.com/terminal-services-manager/articles/how-to-grant-shadow-access-rights-for-users-without-grant-full-admins-rights-in-rds-servers/

Siehst Du, und für Windows-Menschen ist ein Service-Account einer, unter dem ein Dienst ausgeführt wird 😊 Drum frage ich ja.

Ha! Diese Auslegung hatte ich noch nicht gehört, und sie würde ja total einleuchten, wenn man Microsoft vernünftiges Handeln unterstellt. ABER. Nach demselben Prinzip könnten auch Device CALs nicht getrackt werden, denn ein Computer kann 7 OS-Instanzen installiert haben, die nichts voneinander wissen

...wobei return als LETZTE Anweisung innerhalb einer Funktion vollkommen optional ist, sprich, $rueckgabeWert ist äquivalent zu return $rueckgabeWert Erst wenn return dazu verwendet wird, in einem bestimmten Zweig aus der Funktion auszusteigen, entfaltet es eine wirkliche Wirkung. In Klassen sieht es wieder anders aus Dies nur als "unnützes Wissen zum Freitag".

Ich weiß nicht, was ein "Funktionsaccount" in Deiner Welt ist Vielleicht. Aber genau das suchst Du doch, oder?

Moin, im User-Account kannst Du nur die Workstations hinterlegen, von denen aus es sich anmelden darf, und Zeiten. Wenn das DokuWiki (ich nehme an, auf Linux) damit klar kommt, ist das Problem schon gelöst. Für alles andere gibt es Policies ("loklae Anmeldung verweigern", "Anmeldung über remotedesktopdienste verweigern" usw.) womit Du den Member-Maschinen mitteilen kannst, dass dieses Acount sich NICHT dort interaktiv anmelden darf.