ugg.li Schnelle Hilfe für schnelle Admins
Nicht immer schön, aber effektiv. Schnelle Hilfe für schnelle Admins.
Die Einstellung „IP-Filter“ fehlt in der NPS-Konsole 😱
Die Konsole „Als Administrator“ starten 💩 Hint: Das geht auch nicht aus de RRAS-Konsole heraus. Dieser Inkonsistente Mist kann einen Admin Wahnsinnig machen 🤪
Gewisse „Eigenheiten“ in den Windows Server 2016/2019 RDS Diensten (früher „Terminaldienste“) reißen nicht ab.
In vielen Setups klagen Benutzer, wie Administratoren, über sehr langsame Anmeldevorgänge. Man nur einen schwarzen Bildschirm mit seiner Maus darauf und wartet lange bis der Desktop erscheint.
Das können 20 Sekunden sein, wir haben aber auch bis zu 4 Minuten (!) gesehen. An der Leistung der Maschine liegt es nicht.
Der gemeinsame Nenner scheint aber der Einsatz der Sessionhost-Rolle zusammen mit dem Broker/Gateway zu sein und -vor allem- die „User Profile Disks“. So sinnvoll die Erfindung der Benutzereigenen VHDX-Festplattencontainer auch erscheinen mag, der Einsatz der Profilplatten scheint den Anmeldezeit extrem zu verlängern.
Es sind zwar nicht direkt die UPDs, aber eine Eigenheit des ShellExperienceHost im Zusammenhang mit der automatischen Ausführung durch den Dienst „App-Vorbereitung“ (AppReadiness). Es hilft diese Ausführung einfach zu deaktivieren:
Maschine rebooten und neu anmelden. Die Wartezeit sollte nun der Vergangenheit angehören.
Es gibt auch Software, die sich hier mit mehr oder weniger korrekten Schlüsseln verewigt. Ein Test der Schlüssel (anch und nach entfernen und die Anmeldung testen).
Besagter Dienst hat schon einige Probleme, Patches und Probleme hinter sich. Mal durch selbstgemachte Schwierigkeiten, mal durch Anpassungen Dritter. Es scheint hier zumindest größeres Fehlerpotential vorzuliegen …
Die Rolle „Routing und RAS“ als Kernkomponente für den sicheren Fernzugriff via VPN hat seit Windows Server 2016 einen schlechten Ruf. Leider ist dieser unter Server 2019 noch mehr gerechtfertigt; die RRAS Services und deren Konfiguration sind bis zur Unbenutzbarkeit mit Fehlern behaftet.
Neu ist für uns aber der Installationsfehler: Fügt man via „Install-WindowsFeature Routing“ oder dem Server-Manager den RRAS Service hinzu („Remotezugriff“), beschwert sich der Server nach einer erfolglosen Installation:
Der Vorgang kann nicht abgeschlossen werden, da der angegebene Server neu gestartet werden muss.
Ein Neustart hilft hier (natürlich) nicht weiter.
Die Installation scheitert an der WID, der „Internen Windows Datenbank“. WID ist eine SQL Express Instanz, die „Als Dienst anmelden“ Berechtigungen benötigt. Etwas ungeschickt ist hier, das der Dienst als „NT SERVICE“ starten will, der diese Rechte auf DCs (und einigen anderen Rollen) nicht (mehr) hat.
Also muss man die Default Domain Controllers Policy (bei DCs), die Default Domain Policy (bei „Hardened Networks“) oder die jeweils zutreffende Policy anpassen. Das macht man am besten nach einem sauberen Neustart.
Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Zuweisen von Benutzerrechten > Anmelden als Dienst
Hier müssen die folgenden Identities Mitglied sein:
Schliessen, GPUPDATE /FORCE udn schon läuft die Installation fehlerfrei durch.
Das CMDlet Set-RDWorkspace ist unter Windows Server 2019 (wie so vieles andere ebenfalls) kaputt. Man sollte eigentlich den Workspace-Namen so setzen können:
Set-RDWorkspace -Name "Welt der Wunder"
Aber der Befehl produziert nur einen Fehler:
Set-RDWorkspace : Fehler beim Aktualisieren des Arbeitsbereichs für den RD-Verbindungsbrokerserver "FQDN.MEINESSERVERS". Fehler: Ausnahme beim Aufrufen von "Put" mit 0 Argument(en): "" In Zeile:1 Zeichen:1 Set-RDWorkspace -Name "Welt der Wunder"~~~~~~~~~ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Set-RDWorkspace
Den Workspace-Namen und die Beschreibung („Description“) setzt man am besten direkt in der Registry in dem Schlüssel HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralizedPublishing
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralizedPublishing] "WorkspaceName"="Welt der Wunder"
Manchmal macht der (prinzipiell gutmeinende) Windows 10 Offline-Cache, namentlich „Offlinedateien“ oder auch „CSC“ für Client-Side Caching, absurde Sachen. Gerne lässt sich diese fiese kleine Mimose auch durch Serverumzüge verwirren und präsentiert unlösbare Konflike im Synccenter. Es „entstehen“ auch manchmal unlöschbare Ordner, neue Dokumente kommen auf Dateiservern nicht mehr (zuverlässig) an und generell ist das was der Explorer zeigt nicht mehr das selbe was der Explorer auf dem Fileserver auflistet.
In den meisten Fällen hilft ein Zurücksetzen des Caches. Achtung, dabei wird sämtlicher zwischengespeicherter Inhalt entfernt, man sollte also von den betroffenen Daten eine Sicherung haben.
Möglichkeit 1: Cache neu erstellen lassen (liebevolle Variante)
Einen neuen DWORD-Wert (32bit) “ FormatDatabase“ mit dem Wert „1“ erstellen:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CSC\Parameters] "FormatDatabase"=dword:00000001
Danach rebooten.
Die meisten Synchronisationsfehler sind damit schon behoben. Als hätten die Programmierer des CSC geahnt das dieses transparente Caching-Konzept … „anfällig“ sein könnte.
Möglichkeit 2: Cache komplett löschen (krasse Variante)
Der Offline-Cache wohnt in %windir%\CSC. Dieser Inhalt muss komplett entsorgt werden.
takeown /r /f C:\Windows\CSC rd /s C:\Windows\CSC reg add HKLM\SYSTEM\CurrentControlSet\Services\CSC\Parameters /v FormatDatabase /t REG_DWORD /d 1 shutdown -r -f -t 0