cj_berlin

Das kriegt man aber durch unsupportetes Herumfummeln an AD-Attributen auch gelöst. Ich hatte einen Kunden (kam von Lotus Notes), der bereit war, dafür Geld zu bezahlen.

Moin, jetzt mal aber kurz back to basics: Exchange ist gepatcht - CU21 und Juli-SU sind eingespielt? Download Domain für OWA ist eingerichtet? Detection Script aus dem Hafnium-Hack ausgeführt und findet nichts?

Doch. Kommt nur auf den Stundensatz an.

Moin, wenn es ein lokales Konto ist, wird dafür nach Beitritt zu einer (anderen) Domäne kein neues Profil angelegt. Ansonsten, wenn es in Wirklichkeit um Domain-Accounts geht, der Zug schon abgefahren ist und der Einsatz eines Migrationstools (ADMT hätte genügt) nicht mehr zur Debatte steht, musst Du nur einen Registry-Key umschreiben (SID unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList) sowie die Daten und die Registry re-ACLen (für beides hilft SetACL von Helge Klein). Und schon hast Du ein 99,5% funktionierendes Profil.

Du darfst auf einem Domain Member keine DNS-Server eintragen, die die Zone ihrer Domain nicht auflösen können. Set 22 Jahren bekannt.

Das VPN und evtl. Firewalls soweit gerade ziehen, dass die Kommunikation funktioniert?

Bestimmt, aus 9x 8GB Platten. Hatte ich auch mal

OK, das wird jetzt langsam wirklich spannend. @Marco31 welches Verhalten hast Du dir den erhofft? Es gäbe ja in meinen Augen fünf Varianten: Wenn SRP aktiv ist, wirkt AppLocker nicht --> hast nichts gewonnen, oder? Wenn AppLocker aktiv ist, wirkt SRP nicht --> das ist das, was MSFT sich gedacht hat, passt Dir offenbar nicht Wenn beide aktiv sind, greift SRP zuerst --> AppLocker im Audit Mode würde nichts loggen, was verboten werden sollte, denn das würde ja schon von SRP weggeblockt werden Wenn beide aktiv sind, greift AppLocker zuerst --> vermutlich Dein Favorit Wenn beide aktiv sind, greift einer der Mechanismen, der andere kriegt den Ausführungsversuch aber auch dann mit, wenn er vom ersten geblockt wurde. Ansonsten: Um Überraschungen zu vermeiden, RTFM: hier steht schwarz auf weiß: "Verwenden von AppLocker- und Softwareeinschränkungsrichtlinien in derselben Domäne AppLocker wird auf Systemen unterstützt, die Windows 7 und höher ausgeführt werden. Richtlinien für Softwareeinschränkung (Software Restriction Policies, SRP) werden auf Systemen unterstützt, die Windows Vista oder früher ausgeführt werden. Sie können weiterhin SRP für die Anwendungssteuerung auf Ihren Computern vor Windows 7 verwenden, aber AppLocker für Computer verwenden, auf denen Windows Server 2008 R2 Windows 7 und höher ausgeführt wird. Es wird empfohlen, AppLocker- und SRP-Regeln in separaten GPOs zu erstellen und das Gruppenrichtlinienobjekt mit SRP-Richtlinien auf Systeme zu adressieren, die Windows Vista oder früher ausgeführt werden. Wenn sowohl SRP- als auch AppLocker-Richtlinien auf Computer angewendet werden, auf denen Windows Server 2008 R2 Windows 7 und höher ausgeführt wird, werden die SRP-Richtlinien ignoriert."

Das kannst Du in Deinen eigenen Skripten halten, wie Du willst. In Deinem Beispiel benutzt Du aber ein fertiges Cmdlet, und dieses schreibt den Fortschritt hart in den Progress-Outputstream.

Moin, Deine GUI müsste dafür den Progress Buffer auslesen (siehe https://docs.microsoft.com/de-de/dotnet/api/system.management.automation.psdatastreams.progress?view=powershellsdk-7.0.0 ) und dann entsprechend eine grafische Progress Bar zeichnen.

Der G7 hatte auch nur einen FakeRAID, diesen B210i-Controller. Funktioniert nur unter Windows und nur mit dem richtigen Treiber. Die Funktion kriegst Du vom SR100i auch, sie ist nur ehrlicher beschrieben.

Moin, wenn Du bisher mit dem Microserver zufrieden warst, kannst Du halt den Nachfolger nehmen: https://h20195.www2.hpe.com/v2/GetDocument.aspx?docname=a00073554enw Da gäbe es sogar einen kleinen Xeon als CPU Das einzige, was nicht passt, wäre kein Hardware RAID, aber das hatten die Vorgänger ja auch nicht. Ich habe dann immer einen Adaptec-RAID reingesteckt, die Kabelpeitsche passte ganz gut rein. Alternativ gibt es ganz gute Microserver von Thomas Krenn: https://www.thomas-krenn.com/de/produkte/tower-systeme/microserver.html Da kannst Du auch einen RAID-Controller reinkonfigurieren.

Immer wenn Du Journaling pro Postfach konfigurierst, benötigst Du für dieses Postfach eine Enterprise CAL. Eine Lösung mit Standard CAL wäre: Du trennst die SMTP-Domains auf separate Datenbanken. Dann kannst Du das herkömmliche Journaling (auf DB-Basis) verwenden und brauchst keine Enterprise CALs.

Moin, gehört jeder Empfänger jeweils nur einer Domain an? Dann geht es mit dem Premium Journaling (braucht Enterprise CAL). Wenn die Empfänger Adressen aus beiden SMTP-Domains haben und Du möchtest die Mails unterschiedlich archivieren, je nachdem, an welche Domain sie gegangen sind, dann wäre eine Transportregel mit "Add BCC" vielleicht eine Option...

Moin, wenn es wirklich kein Exchange on-prem und keinen Sync zu Azure AD mehr gibt, kannst Du alle Attribute natürlich bereinigen. Allein schon, damit neue und alte Benutzer-Objekte denselben Satz an Attributen bestückt haben. Aber magst Du kurz erklären, was da gelaufen ist? Ihr habt einen Exchange und einen AAD Sync gehabt, und jetzt ist beides weg?

So etwas hier? https://www.vspbreda.nl/nl/ms-office/office-365/name-reference-invalid/

Das Problem oder vielmehr die Aufgabe, die Du lösen wolltest, hast Du uns bisher hartnäckig vorenthalten. SMB1 *und* WINS auf DC sind ein größeres Problem als alles, was auch nur ansatzweise die Netzwerkumgebung notwendig machen könnte. Es ist so, als ob Du aus Ärger, dass man 2021 im Auto keine durchgehenden Sitze mehr vorn einbaut, die Sicherheitsgurte ausgebaut hättest, um besser mit Deiner Freundin schmusen zu können während der Fahrt. Ich hoffe für Dich, dass es Dein eigenes Netzwerk ist. Dann hast Du wenigstens nur Dir selbst geschadet.

Naja, deswegen haben wir uns ja auch angewöhnt, auf die Anforderung "because reasons" mit der Machbarkeitsaussage "it depends" zu reagieren

Nee, man muss die Treiber schon installieren, aber Du hast ja eine Software-Verteilung.... Sind nur zwei Befehle, wenn ich mich recht erinnere.

Hmmm. Die Treiber... einfach verteilen?

+1 für vergiss es einfach

Moin, ich denke, es wird auf die genaue Definition von "funktionioert nicht" ankommen. ABE bezieht sich immer auf die Objekte, die der betreffende Server auch verwaltet, d.h.: ABE auf Fileserver = Shares sowie Ordner + Dateien in den Shares ABE im DFS = Ordner im Namespace Somit muss ABE auf allen Ebenen aktiviert sein, wenn man es auf allen Ebenen haben möchte.

Moin, ad 1. Es ist immer zu unterscheiden zwischen Authentifizierung und Autorisierung. Vertrauen bedeutet lediglich Authentifizierung, sprich: User aus Domäne A kann sich gegenüber Ressourcen aus Domäne B ausweisen. Ob die Ressource ihm den gewünschten Zugriff erlaubt, ist eine Frage der Berechtigungen. Genaugenommen, kannst Du ja auch innerhalb einer Domäne mit Benutzerrechten erreichen, dass ein Benutzer auf gewisse Ressourcen nicht zugreifen kann. Ein wichtiges Stichwort hier ist die Gruppe "Authentifizierte Benutzer". Wenn dieser Gruppe Zugriffe erteilt werden, gelten sie auch für Benutzer, die in vertrauten Domänen authentifiziert wurden. Da diese Gruppe per Default einige Berechtigungen zugewiesen bekommt, entsteht der Eindruck, dass Vertrauensstellungen automatisch auch für Autorisierung sorgen. Er ist aber falsch. ad 2. Zusätzlichen Forest (Resource Forest) nur für Exchange. Bei neuen Implementierungen ist es aus Security-Sicht ohnehin die einzig vernünftige Variante. zu Frage zwei aber noch dies: Schemaänderungen (wenn es nicht um Berechtigungen für vorhandene Attribute geht, sondern um Schemaerweiterungen) sind nicht sicherheitsrelevant. Exchange auf einem Domain Controller zu installieren ist zwar leider nicht unsupported, sollte aber in einer wohlgemanagten Umgebung dringend vermieden werden.

Moin, um die Lizenzierung von welchem Produkt geht es? Was hat der Host physisch drin? Falls HT für Hyperthreading steht, so spielt es für die Lizenzierung keine Rolle - entweder physisch vorhandene Cores (Windows Server) oder vCPUs (SQL) sind zu zählen. Deaktivierte, aber physisch vorhandene Cores sind ein altes Streitthema, nicht nur bei Microsoft. Spätestens wenn es möglich ist, Cores zu de- und wieder zu aktivieren, ohne den Host herunterzufahren, ist es eindeutig und man muss definitiv alle lizenzieren. Ergänzung: Wenn Du ganze CPUs (Sockets) abschaltest, müssen sie nicht lizenziert werden.

Das ist jetzt vielleicht polemisch, aber gilt das nicht für den bisher erreichten technischen Stand der Büro-IT generell, und zwar durchaus herstellerübergreifend? Damit argumentiert MSFT ja, nicht ganz zu unrecht, für die (eigene) Cloud - dabei natürlich geschickt ausblendend, dass sie für den zitierten Grund ja mit verantwortlich sind