cj_berlin

Moin, Herunterfahren ist einfach - lokale Sicherheitsrichtlinie, Zuweisen der Benutzerrechte, das Recht zum Herunterfahren dem Konto entziehen. Sperren - oder auch abmelden - ist schwierig. Je nachdem, was auf diesen Maschinen gemacht wird, könnte der Kiosk-Modus eine Lösung sein, aber ich weiß nicht, wie da der aktuelle Stand ist. Nachtrag - Du könntest, wenn es sicherheitstechnisch vertretbar ist, den "Tagsüber-User" ohne Passwort fahren. Hindert ihn zwar nicht am Sperren, aber auch nicht den Nächsten am Entsperren.

Wenn Twitter nach Deutschland kommt, hat Elon die Adresse e@x.de Und die Leute von der iX haben 2-stellige Kürzel und somit 8-stellige e-Mail-Adressen. Nicht kürzer als Dein samAccountName, aber trotzdem ziemlich geil.

Leider nein. Bin vom 28.03. bis 11.04. weg

Ich bin im März kaum im Lande :-( Nächstes Mal dann...

Moin, Get-ADObject -Filter * -SearchBase "CN=MSA01,CN=Managed Service Accounts,DC=doma,DC=in" -SearchScope Base -Properties tokenGroups, msds-tokengroupnames Wichtig ist, dass SearchScope=Base ist, denn das sind berechnete Attribute Allerdings sind natürlich im Token auch verschachtelte Gruppenmitgliedschaften enthalten. Wenn Dich nur direkte interessieren, dann Get-ADObject -Identity "CN=MSA01,CN=Managed Service Accounts,DC=doma,DC=in" -Properties memberOf DANN verpasst Du aber natürlich wiederum die Primary Group, denn diese ist nur über die primaryGroupID den Mitgliedern zugeordnet...

Moin, wie ich oben bereits schrieb, hast Du (vermutlich, aus Deiner Schilderung) kein ADWS-Problem, sondern ein AD-Problem. ADWS läuft, aber das AD oder vielmehr der DC fällt ab und zu aus, udn ADWS meldet das mit der Fehlermeldung aus dem OP. Dein NTDS-Log muss knallrot sein bei dem Befund, auch DNS Server-Meldungen und einiges mehr. Ich habe so die Vermutung, dass wir im Rahmen des Forums die notwendige Diagnose nicht werden vornehmen können. Such Dir ein zweites Paar Augen, am besten jemanden, der solch ein AD-Troubleshooting schon mal gemacht hat. Der Src Root Domain Srv ist der DC, von dem dieser DC bei seiner Promotion die forestweiten Partitionen repliziert hat, also wenn die Domäne älter ist als 2008, wird da natürlich ein anderer Server drin stehen

Genau.

Moin, ultimativ lösen --> da muss man sich mit Deinem anderen Thread und Deinem AD beschäftigen. jetzt das AD PowerShell-Modul in Gang bringen --> versuch mal, das Ganze auf dem 2008er DC zu starten oder auf einer anderen Maschine, aber den 2008er DC im Parameter -Server anzugeben.

PowerShell 7 ist NICHT die neueste Version von PowerShell, es ist ein separates Produkt. Alle Built-In-Cmdlets von Windows Server-Rollen sind für Windows PowerShell 5.1 entwickelt, und wenn Du sie aus PowerShell 7 aufrufst, wird unter der Haube ein Kompatibilitätsmodus gefahren. Du musst Dein AD reparieren, dann wird auch ADWS funktionieren, und damit auch das PowerShell-Modul.

Moin, wenn Du auf einem Server 2016+ oder Windows 10+ bist, hast Du die neueste. Du hast ja das ADWS-Thema gepostet, das hängt damit zusammen,

Moin, was Du vorhast ist technisch möglich. Wenn der Forest nur eine Domäne hat und keine Vertrauensstellungen zu anderen Forests, ist der Gruppen-Scope weniger wichtig. Es gibt Feinheiten wie Token Size, aber generell kannst Du die Gruppen konvertieren, und es dürften dem keine Gruppenverschachtelungen im Wege stehen, denn auch mögliche Mitglieder sind identisch. Ich bin aus Erfahrung kein Freund von Mail-Enabled Security Groups, und wenn Hybrid oder Migration zu Exchange Online am Horizont ist, würde ich dringend davon abraten. Zumindest in der Koexistenzphase, wenn ein Teil der Postfächer on-prem und ein anderer Teil online ist, wird das unschön. Falls ihr diese Gruppen automatisiert, z.B. aus einem IAM-System bestückt, würde ich prüfen, ob's nicht möglich wäre, einfach ZWEI Gruppen pro Entitlement zu pflegen - eine Security-Gruppe für die Zuweisung und eine Verteilergruppe für den Mailversand. Was auch immer Du tust, stell sicher, dass die Gruppen im Sinne des Bei- und Austritts "geschlossen" sind, so dass die Mitgliedschaften nur administrativ gepflegt werden können und nicht durch die Benutzer selbst über Outlook.

Korrekt. Nützt auf dem RODC ohne Netz eh nix

ABER - für RODCs kannst Du ein Konto cachen, das Du dann im managedBy-Attribut des RODC Computer-Objekts hinterlegst. Dieser User kann dann den RODC administrieren.

ich meine auf einem schreibbaren Domain Controller lokal ohne Netzwerk mit einem Admin, der in Protected Users ist, anmelden.

Hier funktioniert's. Frisches Account angelegt, Domain Admins + Protected Users. Kabel von DC abgezogen, rebooted, lokale Anmeldung funktioniert. Aber natürlich nur lokal. RDP ist nicht lokal, und RDP schließt sich mit "kein Netzwerk" auch gegenseitig aus.

Moin, klar können sie sich lokal anmelden, wenn sie aus derselben Domäne sind. Der DC kennt ja deren Kennwörter...

Moin, ist "http://" ohne S da oben in der URL ernst gemeint, also aus einem tatsächlichen Browser rauskopiert? Dann ist es genau das, wonach ich suchen würde

Moin, bleibt die ganze Maschine, also ALLE Sessions, stehen, oder nur einzelne Sitzungen, während andere normal weiter laufen?

Moin, ich gehe jetzt nicht davon aus, dass "die Nutzer" das PowerShell-Modul für AD verwenden oder irgendeine andere Applikation, die explizit auf ADWS zugreift. Wenn diese Annahme zutreffend ist, dann ist es Dein AD (NTDS), das aufhört zu funktionieren, denn ADWS kannst Du normalerweise abschalten und keiner merkt's. Somit ist die zitierte Fehlermeldung zwar zutreffend, aber der Fehler liegt in einem anderen System

Moin, danke für die Rückmeldung. Unter \\domain.fqdn sieht man ja, außer SYSVOL und NETLOGON, nicht Freigaben, sondern erst mal Namespaces. Habt ihr tatsächlich um die Hundert Namespaces, und unterscheiden sie sich auch wirklich voneinander (Namespace Server und Version)? Wieviele Ordner hat denn jedes Namespace? Vielleicht wäre ein Zusammenfassen von 100 Namespaces zu deutlich weniger, vielleicht sogar nur einem, eine Option? Dann könnte man auf \\domain.fqdn\ingloriousfolders gehen und den vollständigen Überblick (minus NETLOGON und SYSVOL, aber die kennt man ja) bekommen?

OK, aber funktioniert ADWS nach dem Neustart bis der Fehler kommt? Vielleicht ist das Problem ja nicht in ADWS, sondern in NTDS zu suchen...

u.a. weil andernfalls sich auch die Koexistenz mit Exchange 2019 schwierig gestalten würde

Moin, schau mal ob der Fehler nach einem Neustart von ADWS wieder kommt, ansonsten: https://techcommunity.microsoft.com/blog/askds/active-directory-web-services-event-1202/1514401

Moin, da Desktop Experience mit Server 2016 abgeschafft wurde, ist es sehr unwahrscheinlich, dass jemand damit einschlägige Erfahrungen unter 2019 oder 2025 gemacht hat. In 2025 sind zumindest Teile der ursprünglichen Desktop Experience wie Microsoft Store und somit die Unterstützung für Windows Apps in das Server OS zurückgekehrt, aber nicht als Sammel-Feature, sondern einfach als Mainstream.

RemoteFX ist ein separater Channel und wird nur durch die dortigen GPOs gemanagt.