Ebenezer

Hallo Zusammen, @testperson Genau, die Gruppe die man in der Sammlung unterhalb von "Benutzergruppen" einträgt, landet auf den Session Hosts in der lokalen Gruppe der Remote Desktop Benutzern! Das muss auch so sein! Es muss also noch einen anderen Mechanismus geben der dafür sorgt, dass sich ein Nutzer, der sich zwar in der lokalen RDP-Gruppe befindet, trotzdem nicht direkt auf einem Session Host anmelden kann, es sei denn er wird über den Broker verteilt! @testperson Ich lande immer auf dem Session Host den ich auch via IP angegeben habe, und zwar mit unterschiedlichen Nutzern!

Hi, hat hier schon Jemand eine 2025er RDS-Farm in Betrieb und ist zufrieden? Ich bin gerade dabei eine aufzubauen und frage mich ob ich besser auf 2022 wechseln sollte. Zum Setup: VM1 -> RDS-Connection-Broker, RDS-Web-Access, and RDS-Licensing VM2-4 -> RDS-RD-SERVER Meine Probleme: 1. Benutzer können sich direkt (via IP oder DNS) auf den Session-Hosts anmelden... das sollten doch eigentlich nur Admins können, oder nicht? Ich habe hier noch eine andere 2022er RDS-Farm und da erhalten die Nutzer beim direkten Anmeldeversuch die Meldung "Der angeforderte Zugriff auf eine Sitzung wurde verweigert". Sie müssen sich also über den Broker verbinden lassen und so soll das auch hier sein! 2. Eine Benutzer-GPO (Laufwerk-Mapping) die mit der Benutzer-OU verknüpft ist, wird nicht angewendet! GPRESULT /H zeigt sie nicht an! Sie wird auch nicht gefiltert! Andere User-Policys die nicht mit der OU sondern der Domain verknüpft sind funktionieren! Im Eventlog steht auch nichts. Ich bin für alle Ideen dankbar!

Hi, ich habe ein Tool gefunden um die Rechte für den Service Control Manager zu ändern: https://systeminformer.io/ (Tools -> Permissions -> Service Control Manager) Ich habe folgende Berechtigungen gegeben: Connect, Enumerate services, Query lock status, Read permissions Damit lassen sich auch Berechtigungen von Windows Diensten sehr einfach anpassen (brauchte ich für div. Third-Party-Dienste). So klappt das nun prima - ganz ohne Adminrechte und NTLM!

Danke für Eure Antworten! Wir wollen via PRTG ohne Admin-Rechte den Status von Diensten monitoren! Für andere Klassen funktioniert das mittlerweile via WSMan und KERBEROS problemlos, aber leider nicht für die Dienste: https://blog.paessler.com/more-security-better-performance-wsman-and-kerberos-authentication-for-wmi-sensors-in-prtg https://helpdesk.paessler.com/en/support/solutions/articles/76000088235-how-can-i-use-a-non-administrator-windows-account-for-wmi-monitoring-via-the-wsman-protocol- Die Berechtigungen nur für den überwachenden Dienst zu ändern, bringt leider auch nichts: https://www.der-windows-papst.de/2020/09/18/allow-users-to-manage-windows-services/ Da fehlt vermutlich das generelle Recht für den SC-Manager, oder? Kann man der Gruppe "Remoteverwaltungsbenutzer" dieses Recht nicht irgendwie einräumen? Ich komme derzeit an den lokalen Adminrechten nicht vorbei... immerhin erfolgt die Authentifizierung nun vermeintlich sicher via KERBEROS und nicht mehr via NTML, aber ideal ist das immer noch nicht!

Hi, wir versuchen im LAN den Dienst-Status auf div. Windows Servern 2016 / 2019 ohne Admin Berechtigungen abzufragen und scheitern: Get-CimInstance Win32_Service -Filter "Name='Spooler'" -ComputerName server01 Get-CimInstance : Der WS-Verwaltungsdienst kann die Anforderung nicht verarbeiten. Der WMI-Dienst hat einen "Zugriff verweigert"-Fehler zurückgegeben. In Zeile:1 Zeichen:1 + Get-CimInstance Win32_Service -Filter "Name='Spooler'" -ComputerName + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : PermissionDenied: (:) [Get-CimInstance], CimException + FullyQualifiedErrorId : HRESULT 0x80338104,Microsoft.Management.Infrastructure.CimCmdlets.GetCimInstanceCommand + PSComputerName : server01 Folgender Befehl funktioniert hingegen mit eingeschränkten Rechten! Get-CimInstance Win32_OperatingSystem -ComputerName server01 Wie löst Ihr das Problem? Danke!

Hi, also bei uns war das FSLogix Profil inaktiv, sobald man nicht in der Include List war! War man Mitglied so wurden, wie bei Dir auch, aber immer beide Profillösungen parallel genutzt! Wir mussten also UPD in den Farmeinstellungen deaktivieren und musste alle Profile zeitglich auf FSLogix umstellen! Dann hatten wir noch das Problem, dass die Anmeldungen zunächst mehrere Minuten dauerten... die Lösung war dann den Schlüssel HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Notifications zu löschen: https://koetzingit.de/index.php/news-de/10-newsflash-de/37-citrix-de/241-langsame-windows-anmeldung-durch-aufgeblähte-registry Bei uns ging das auch nur manuell via Registry, weil das Script, vermutlich aufgrund der Größe, immer abschmierte!

Danke!

Hi, mittlerweile gibt es folgenden Microsoft Artikel zur Problematik: https://support.microsoft.com/en-us/topic/kerberos-and-ntlm-authentication-failures-due-to-duplicate-sids-76f7394d-c460-4882-9ed1-d27e0960f949 Nicht eindeutige Computer SIDs können also, zumindest in bestimmten Konstellationen, nach zwei Jahrzehnten wieder zum Problem werden! im Lösungs-Abschnitt des o.a. Artikels ist noch von speziellen Gruppenrichtlinien die Rede, mit denen man dem Problem temporär begegnen kann. Allerdings muss man diese über den Microsoft Business Support erfragen. Hat das zufällig schon Jemand gemacht und hat Lust seine Erkenntnisse zu teilen? Danke!

Auch das Skript funktioniert nicht? Was hattest Du für Probleme, weißt Du das noch im Detail?

Hi, wir müssen eine RDS Farm von UPD auf FSLogix umstellen. Pro RDSH legt FSLogix u.a. die lokale Gruppe "FSLogix Profile Include List" an, in der standardmäßig "Jeder" Mitglied ist! Hier haben wir Jeder rausgeschmissen und eine AD-Gruppe mit einem Test-Account hinzugefügt! In den zentralen Farm-Einstellungen ist der Benutzerprofil-Datenträger logischerweise für alle aktiviert... ich hatte gehofft, dass FSLogix das übersteuert / aushebelt und wir über die o.a. AD-Gruppe die Benutzer nach und nach migrieren können, aber das scheint nicht so zu sein! Versucht man sich anzumelden dann bleibt das Anmeldevorgang bei "Bitte warten Sie auf FSLogix Apps Services" hängen... im Hintergrund wird zwar ein VHDX-Container angelegt, aber mehr passiert nicht! Kann man wirklich nur alle Benutzer auf einmal migrieren oder fällt hierzu Jemanden noch etwas ein? Falls ja, hat Jemand schon folgendes Skript für die Migration verwendet? https://github.com/gregdod/FSLogixMigration Danke!

Mein Tenant hatte gestern beim ersten Sync auch noch "Flüssigkeitsmangel"... beim zweiten Versuch lief dann aber alles durch!

Es lag an der fehlenden Exchange Lizenz! Aussagekräftige Fehlermeldungen sind doch was Schönes... Danke an Alle!

Ich teste und gebe Feedback!

Den Haken habe ich gar nicht gesetzt! Die App wird wohl dennoch registriert! Ich habe mich gerade mal mit einem anderen M365 Tenant verbunden... da bin ich weiter gekommen und hätte die App registrieren können... es muss also etwas mit dem Tenant zu tun haben... der Tenant zu dem ich verbinden möchte verfügt noch über keinerlei Lizenzen, weiß Jemand ob das eventuell ein Problem sein könnte?

Danke... also die ExchangeServerApp wurde in EntraID auf jeden Fall nicht erstellt! In den Anmeldeereignissen sehe ich u.a. als client application "Microsoft Exchange Hybrid Wizard" aber die Ergebnisse bei den Authentifizierungsdetails sind erfolgreich! 2025-10-16T10:27:04.0000000Z Password: Password in the cloud Correct password 2025-10-16T10:27:04.0000000Z Mobile app notification: MFA successfully completed Mehr kann ich hier nicht erkennen!

Hi, ich versuche von einem Exchange 2016 nach Exchange Online zu migrieren. EntraID Connect ist eingerichtet. Leider ärgert mich der HCW nachdem ich bereits eine Verbindung zum Tenant herstellen konnte und "Vollständige Hybridkonfiguration" und dann "Klassische Exchange-Hybridtopolgie" ausgewählt habe, mit der beigefügten Fehlermeldung! Unter %appdata%\microsoft\Exchange Hybrid Configuration\*.log sehen die letzten Zeilen dann so aus: 2025.10.16 10:37:38.277 10265 [Client=UX, Page=OnPremisesAppConfiguration, Thread=1] START via Next 2025.10.16 10:37:38.278 10453 [Client=UX, fn=SendAsync, Thread=25] START GET https://graph.microsoft.com/beta/62c31755-cf19-463e-9257-e03846c05be7/Applications?$filter=displayName eq 'ExchangeServerApp-f1ef2343-8b8b-4216-8835-5d078e8cf539' 2025.10.16 10:37:38.486 10454 [Client=UX, fn=SendAsync, Thread=25] FINISH Time=208,0ms Results=OK {"@odata.context":"https://graph.microsoft.com/beta/$metadata#applications","value":[]} 2025.10.16 10:37:38.486 10453 [Client=UX, fn=SendAsync, Thread=25] START GET https://graph.microsoft.com/beta/62c31755-cf19-463e-9257-e03846c05be7/ServicePrincipals?$filter=appId eq '00000002-0000-0ff1-ce00-000000000000' 2025.10.16 10:37:38.653 10454 [Client=UX, fn=SendAsync, Thread=25] FINISH Time=167,0ms Results=OK {"@odata.context":"https://graph.microsoft.com/beta/$metadata#servicePrincipals","value":[]} Das einzige was ich dazu bei Microsoft finden konnte und was aber auch nicht ganz passt ist folgendes: https://learn.microsoft.com/en-us/troubleshoot/exchange/hybrid-configuration-wizard-errors/object-reference-not-set-to-an-instance-of-an-object-error Meint Ihr ich habe hier eher ein Exchange- / AD-Problem? Was meint es mit "Exchange Server-Anwendungskonfiguration"? Danke!

Hallo Jan, danke das klingt exakt nach unserem Problem! Wie bist Du auf diesen Thread gestoßen?

Hi, 2x Windows 1124H2 mit aktuellen Updates. Auf einem PC ist das Datenlaufwerk via "D%" freigegeben! Seit einem der letzte MS Updates funktioniert der SMB Zugriff vom anderen PC nicht mehr! Auf beiden Systemen befindet sich ein gleichnamiges Benutzerkonto (mit Adminrechten) und auch die Kennwörter sind identisch! Das Security Eventlog wirft folgendes aus: Bei der Anmeldung ist ein Fehler aufgetreten (Ereignis-ID: 4625)! Diese ID sieht man auch, wenn man ein falsches Kennwort eingibt, allerdings ist dann der Fehlertext ein anderer (Benutzername oder Kennwort falsch)! Was wir schon alles probiert haben: - Die Anmeldeinformationsverwaltung geleert und beide Systeme neugestartet - Die Verbindung über andere Accounts (z.B. den integrierten Administrator) probiert - Verschiedene Schreibweisen ausprobiert (\\smbserver_hostname\username) oder (\\smbserver_ip\username) oder auch nur (username) - Eine neue sichtbare Freigabe erstellt - Insecure Guest Logins erlaubt (https://learn.microsoft.com/en-us/answers/questions/2189515/windows-11-24h2-and-insecure-guest-logins-settings?forum=windowsclient-all&referrer=answers) Fällt sonst noch Jemandem etwas dazu ein, oder muss man da jetzt mit Wireshark ran? Danke!

Ich wüsste nicht wie! Ich habe den DC soeben erneut falsch umbenannt und anschließend im DSRM-Modus gestartet. Jetzt frag ich den neuen DC Namen ab: netdom computername NeuerDC /enumerate Ergebnis: NeuerDC.testlab.local (Der Befehl wurde ausgeführt) Frage ich den alten DC Namen ab erhalte ich: Der Netzwerkpfad wurde nicht gefunden! Versuche ich dann mit dem u.a. Befehl den alten DC Namen als Alternativen Namen zu setzen, erhalte ich folgenden Fehler: AlterDC.testlab.local konnte nicht als alternativer Name für den Computer hinzugefügt werden! Fehler: Eine vorhandene Verbindung wurde vom Remotehost geschlossen. netdom computername NeuerDC.testlab.local /add:AlterDC.testlab.local

Hi, ich habe das Szenario gestern in einem Lab durchgespielt... also das umbenennen via GUI führte auch hier zu dem Anmeldefehler "Die Sicherheitsdatenbank auf diesem Server verfügt über kein Computerkonto"! Ich hatte zuvor via wbadmin ein systemstate backup ausgeführt. Dieses habe ich dann wiederhergestellt und konnte mich dann auch wieder anmelden! Wenn man das nicht hat, dann ist mir kein Weg bekannt aus der Nummer wieder rauszukommen! Anschließend habe ich dann das umbenennen via netdom (wie auch hier beschrieben https://www.der-windows-papst.de/2021/06/24/rename-domain-controller/) ausgeführt und es gab keine Probleme! Danke für Euren Input!

Ich konnte das leider nicht mehr ausprobieren, weil wir uns dazu entschlossen haben die Domain neu einzurichten. Diese ist glücklicherweise sehr klein und da neue Computer angeschafft wurden (Wechsel von Windows 10 auf 11) mussten wir diese ohne in die Domain aufnehmen! Ich war mir so sicher, dass es keine Schwierigkeiten macht einen DC (ohne Exchange) wie beschrieben umzubenennen, dass ich dazu im Vorfeld auch nichts mehr nachgelesen habe! Das war ein Fehler! Doppelt ungünstig wenn dann auch so schnell kein Backup einspringen kann. Aber alles eigenes verschulden! Danke für Eure Hilfe-Versuche!

Ich habe das Computerkonto des DCs via GUI umbenannt (Einstellungen -> Info -> Diesen PC umbenennen)! Seitdem besteht das Problem!

Ja ich habe das Computerkonto umbenannt und kann es aber scheinbar via DSRM nicht wieder rückgängig machen!

Ich bin als Administrator im DSRM angemeldet! Ein umbenennen des Computerkontos ist in diesen Kontext scheinbar nicht möglich!

Wie denn? Er sagt das geht nicht im DSRM Modus! Wir haben es vergeblich via GUI und PowerShell probiert (rename-computer)!