cj_berlin

Ich find's prima, dass Du es prima findest. Mir läuft es kalt den Rücken herunter. Ein Terminalserver braucht kein DHCP. Auch keine weitere Domäne, und schon gar keine wie bisher, wo die User lokal auf dem Domain Controller laufen. IGEL Thin Clients sind normalerweise nicht AD-Mitglied, daher dürfte es egal sein, in welcher Domäne welcher Terminalserver steht. Wie viele Lehrer und wie viele Schüler sollen auf diese neue Umgebung zugreifen, und von welchen Endgeräten sollen die Schüler das tun?

Das steht im Client-Log, Event 8001, Feld "Target Name". Vielleicht

Moin, "state switchover interval" (SSI) ist die "elastizität des Clusters". Wenn Deine Lease-Time nicht in Sekunden bemessen wird und Du den aktiven Knoten einfach nur mal rebooten möchtest, muss es doch noch lange keinen Failover auslösen. Dieser Wert zeigt, wie lange der Knoten wartet bis er annimmt, dass der andere so schnell nicht wieder kommen wird. "Max Client Lead Time" (MCLT) ist die maximal mögliche Verlängerung eines Lease, der durch den anderen Knoten vergeben wurde und die Dauer des Leases, die vom passiven Knoten ausgeteilt werden, wenn der aktive "down" ist und das SSI noch nicht abgelaufen ist. Die Kombination beider Werte ergibt das Verhalten, wenn der aktive Knoten ausfällt: Nach SSI beginnt der ehemals passive Knoten, Anfragen zu beantworten, und nach MCLT ist er dann nicht nur aktiv, sondern auch der Owner aller Leases. Aus Ops-Sicht mag ich Aktiv-Passiv-Cluster jeder Art nicht, *besonders* in KMUs, denn man findet nie Zeit, Failover regelmäßig zu testen, und dann eines Tages knallt's.

Ja, das geht. Du musst das Löschrecht auf "Files Only" beschränken, und das "Create Files" recht auf "Subfolders Only". Und natürlich die Vererbung der darüber hinausgehenden Rechte wegnehmen. Alternativ kannst Du die vererbten Rechte in Ruhe lassen und einen expliziten Deny auf "Delete" für diese Gruppe, in diesem Fall beschränkt auf "Subfolders Only", am "Eingang Logistik" verhängen. Ob David damit uneingeschränkt klar kommt, hätte ich Dir vor 20 Jahren aus dem Kopf sagen können, aber jetzt nicht mehr...

Wegen NTLM im normalen Registrierungsprozess mit certmgr.msc? Ich würde das NTLM-Logging auf beiden Seiten hochdrehen und schauen, was da aufgerufen wird, evtl. fehlt doch ein SPN...

Also zwei Server, die jeweils mehr als 50% brauchen, das erinnert schon fast an den Bundeshaushalt Habt ihr im LB-Betrieb eine sehr ungleiche Verteilung? Dann vielleicht mit den Netzwerkern sprechen, damit sie sich die Helper nochmal angucken? Ich habe es mal erlebt, von "selbstbau-HA" mit Server 2003R2 auf echtes HA mit Server 2012R2 migriert und nie Leases am zweiten Server gesehen. Stellt sich heraus, der Helper für Server 2 hatte einen Delay switch-seitig. Doch selbst wenn der Pool am ersten Knoten mal erschöpft ist: was glaubst Du, was dann passiert?

Allerdings, und das meine ich ernst, muss mir jemand mal zeigen, WIE er diese Website heutzutage noch benutzt, basiert die Ausstellung von Zertifikaten doch auf ActiveX-Controls...

Klar, jeden Tag, wenn Du die BSI- oder CIS-Härtung anwendest, dann wird der letzte angemeldete Name nicht vorbelegt.

Das ist die ACL, die jedes Objekt von seiner Klasse im Schema mitgegeben bekommt, wenn es erstellt wird. Wenn Du dir ein neues Objekt anschaust und die Berechtigungen unter "Advanced" auflistest, dann gibt es halt Einträge, die nicht vererbt sind. Das sind diese

genau. das ist ja der Sinn von "übernommen" --> es ist dann "ihre eigene" Domain

Manche, die ich so kriege, kommen mit valider DKIM-Signatur.

Moin, RDS-Lizenzierung ist niemals "concurrent" und ist es nie gewesen, daher schrieb ich oben Ansonsten, was @Nobbyaushb und ich auch bereits angemerkt haben - vergiss die zwei gleichzeitigen Sitzungen. Die sind für die Verwaltung des Servers und der darauf installierten Anwendungen, NICHT für die Benutzung. Andererseits, wenn ein Device lizenziert wurde (nein, nicht MAC-Adresse, die RDS-Lizenzierung funktioniert anders), können sich von diesem Device beliebige - und beliebig viele - User anmelden, Admin oder nicht. Ich bin generell kein Fan von VPN, aber ALLES ist besser als RDP ungeschützt ins Internet zu stellen, also per dieser Definition auch VPN

"PAT" ist das, was sein Router als "NAT" anbietet.

Moin, seltsame Formatierung, Ist es ein Copy/Paste aus einem anderen Forum? Dann bitte auf Cross-Post hinweisen. Das Wichtigste vorab: Du willst NICHT Port 3389 per NAT ins Internet stellen. Es sei denn, alle zugreifenden Clients haben feste IPs, und Du erlaubst nur diese auf der Firewall Deines Routers. Aber eigentlich auch dann nicht. Tust Du es dennoch, wird Dein Server nur damit beschäftigt sein, falsche Anmeldungen abzuweisen, bis die erste nicht falsch ist, und dann ist es nicht mehr Dein Server. Ansonsten: Neben RDS-Rolle aktivieren, musst Du dem Server noch den zuständigen RDS-Lizenzserver und den Lizenzierungstyp mitteilen. Der Typ, falls Du kein AD hast, kann nur "per Device" sein, der Lizenzserver kann auf demselben Windows Server aktiviert sein, und dort musst Du die RDS CALs einspielen - so viele, wie es unterschiedliche Devices gibt, von denen aus Deine User zugreifen werden. Aber da gibt es eine Karenzzeit. Dass bereits jetzt immer noch zwei Sessions möglich sind, ist ein Hinweis darauf, dass - vielleicht, nur vielleicht? - Deine "User" alle lokale Admins auf dem Server sind. Das ist natürlich auch nicht zielführend. Die Gruppe der Remotedesktop-Benutzer existiert auch lokal.

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,