Lange Anmeldung mit "Blackscreen" bei der Anmeldung an der RDS-Farm

[kaineanung 14]

Hallo Leute,

 

ich habe ein Problem bei dem ich alleine nicht mehr weiterkomme und hoffe hier Hilfe zu finden.

 

Das ist was wir hier haben / einsetzen:

Die RDS-Farm:

• 1x Connectionbroker / Lizenzierungsserver / WebAccess-Server
• 3 RDS-Hosts (2 sind in einer Sammlung und einer in einer anderen Sammlung)
• 1x Fileserver als UPD-Server (Userprofile)

Alle Server laufen auf Microsoft Windows Server 2016 STD. Jeden Monat auf den neusten Stand aktualisiert (Standard-Update).

 

Die komplette RDS-Farm ist Virtualisiert und läuft auf folgenden Hostern:

• ESXi vSphere 6.7.0-HP-Customized-Maschine (ProLiant DL380 G7 12 CPUs Intel Xeon X5690 3.47 Ghz mit 60 GB RAM (-> RDS-Server (CB, WA & Lizenzierungsserver), Fileserver (UPD) und 1x SessionHostServer)
• ESXi vSphere 6.7.0 in einem vCenter mit SAN (ThinkSystem SR650, Intel(R) Xeon(R) Gold 6136 CPU mit 24 echten CPUs bzw. 48 logische CPUs @ 3.00GHz und 500 GB RAM

 

Das Problem:

User melden bei der 'Hauptsammlung' (2x SessionHosts-Server -> ca. 50 User allerdings gleichzeitig max. 15-20) immer öfter daß die Anmeldung teilweise 10-20 Minuten dauert und sie während dessen einen schwarzen Bildschirm bekommen. Dies tritt gleich nachdem der Standard-Anmeldebildschirm verschwunden ist (Anmeldung wurde verifiziert, Gruppenrichtlinien wurden geladen, und nun soll der Desktop angezeigt werden -> schwarzer Bildschirm kommt stattdessen).

 

Es ist nicht immer so, bei 2 Test-Usern hat es mal 20 Sekunden gedauert und dann aber auch mal 2 Minuten (dies jedoch dann beim ersten Anmelden nach einem Neustart) und bei einem dann auch 40 Sekunden. Bei keinem war es wie gewohnt daß der Desktop schon nach 2-3 Sekunden 'Blackscreen' da war.

 

Ich habe natürlich recherchiert zu diesem Fehler und bereits ein paar Ansätze gefunden und ausprobiert. Leider war keine Lösung dabei.

Erfolglose Dinge dich ich also bereits getan habe sind:

• audiodg.exe beenden
• Diverse Dienste beendet und auf Deaktiviert gestellt was Audio angeht -> habe sowieso keine Soundkarte am Server und wird aktuell nicht benötigt
• Powerschell-Skript ausgeführt welches die "Firewall-Regeln", die sich mit der Zeit ansammeln, löscht. War bei diesem Server ca. 53K und hat ca. 1-2 Stunden gedauert.

 

In der Ereignisanzeige habe ich keine Fehler, jedoch ein paar sporadische Warnungen. Hier eine die wahrscheinlich mit der RDS zu tun hat (aber wohl nichts mit meinem Problem zu tun hat):

Protokollname: Application
Quelle:        Microsoft-Windows-User Profiles Service
Datum:         10.09.2021 11:44:08
Ereignis-ID:   1534
Aufgabenkategorie:Keine
Ebene:         Warnung
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      srv-rdsh01.XXXX.local
Beschreibung:
Die Beschreibung für die Ereignis-ID "1534" aus der Quelle "Microsoft-Windows-User Profiles Service" wurde nicht gefunden. Entweder ist die Komponente, die dieses Ereignis auslöst, nicht auf dem lokalen Computer installiert, oder die Installation ist beschädigt. Sie können die Komponente auf dem lokalen Computer installieren oder reparieren.

Falls das Ereignis auf einem anderen Computer aufgetreten ist, mussten die Anzeigeinformationen mit dem Ereignis gespeichert werden.

Die folgenden Informationen wurden mit dem Ereignis gespeichert: 

Delete
{709E2729-F883-441e-A877-ED3CEFC975E6}
Das System kann die angegebene Datei nicht finden.


Das Handle ist ungültig

 

 

So, jetzt meine Frage und meine Hoffnung:

Kennt jemand das Problem und hat eine Lösung dafür? Ich verzweifle mit den Dingen und bin kurz davor die 2 Session-Hosts neu aufzusetzen. Kann aber sein daß nach einer Neuinstallation in ein paar Monaten das gleiche Problem wieder auftritt.. daher wäre mir eine Lösung lieber.

 

Übrigens: an dem dritten Session-Host-Server, welcher alleinig in einer Sammlung steht, habe ich das Problem nicht. Diese Umgebung ist aber relativ neu und wird nur von 3-5 Usern verwendet.

[testperson 1.707]

Hi,

 

ich würde spontan auf die Windows Firewall und sich duplizierende Regeln tippen. Dazu findet sich in diesem Technet Thread (https://social.technet.microsoft.com/Forums/en-US/992e86c8-2bee-4951-9461-e3d7710288e9/windows-servr-2016-rdsh-firewall-rules-created-at-every-login?forum=winserverTS) ein PowerShell Script und in diesem KB (https://support.microsoft.com/en-us/topic/november-27-2018-kb4467684-os-build-14393-2639-7eb61afe-e3de-b34d-0d30-a77670f355fe) ein Registry Key.

 

Das Script wäre auch griffbereit:

# Quelle: https://social.technet.microsoft.com/Forums/en-US/992e86c8-2bee-4951-9461-e3d7710288e9/windows-servr-2016-rdsh-firewall-rules-created-at-every-login?forum=winserverTS
 
$RegPath = "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy"
$Name = "DeleteUserAppContainersOnLogoff"
$Value = "1"
 
Remove-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System\*" -Recurse -Force
Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System\" -Name * -Force
 
$FWInboundRules = Get-NetFirewallRule -Direction Inbound |Where {$null -ne $_.Owner} | sort Displayname, Owner 
$FWInboundRulesUnique = Get-NetFirewallRule -Direction Inbound |Where {$null -ne $_.Owner} | sort Displayname, Owner -Unique
 
Write-Host "# inbound rules: " $FWInboundRules.Count
Write-Host "# inbound rules (Unique): " $FWInboundRulesUnique.Count 
 
if($FWInboundRules.Count -ne $FWInboundRulesUnique.Count) {
    Write-Host "# rules to remove: "(Compare-Object -referenceObject $FWInboundRules  -differenceObject $FWInboundRulesUnique).Count
    Compare-Object -referenceObject $FWInboundRules  -differenceObject $FWInboundRulesUnique   | select -ExpandProperty inputobject |Remove-NetFirewallRule
}
 
$FWOutboundRules = Get-NetFirewallRule -Direction Outbound |Where {$null -ne $_.Owner} | sort Displayname, Owner 
$FWOutboundRulesUnique = Get-NetFirewallRule -Direction Outbound |Where {$null -ne $_.Owner} | sort Displayname, Owner -Unique
Write-Host "# outbound rules: "$FWOutboundRules.Count
Write-Host "# outbound rules (Unique): "$FWOutboundRulesUnique.Count 
 
if($FWOutboundRules.Count -ne $FWOutboundRulesUnique.Count){
    Write-Host "# rules to remove: "(Compare-Object -referenceObject $FWOutboundRules  -differenceObject $FWOutboundRulesUnique).Count
    Compare-Object -referenceObject $FWOutboundRules  -differenceObject $FWOutboundRulesUnique | select -ExpandProperty inputobject |Remove-NetFirewallRule
}
 
if(!(Test-Path $RegPath)){
    New-Item -Path $RegPath -Force | Out-Null
    New-ItemProperty -Path $RegPath -Name $Name -Value $Value -PropertyType DWORD -Force | Out-Null
} else{
    New-ItemProperty -Path $RegPath -Name $Name -Value $Value -PropertyType DWORD -Force | Out-Null
}

 

Gruß

Jan

[daabm 1.366]

vor 6 Stunden schrieb kaineanung:

Anmeldung teilweise 10-20 Minuten dauert und sie während dessen einen schwarzen Bildschirm bekommen.

 

Was gibt's denn so an Logon-Skripts per GPO? Das klingt sehr nach einem Skript, das hängen bleibt...

[testperson 1.707]

Oh, ich merke grade, dass mein Beitrag ja bereits abgearbeitet wurde. Da war ich beim Lesen scheinbar ein wenig "abwesend". :)

[Weingeist 159]

Ich finde es erbärmlich, dass der Krempel mit den Rules schon seit Jahren immer noch nicht konfigurierbar ist. Solche Pauschale Freigaben sind ja eigentlich Datenschutz- und Sicherheitsrelevant. Ab 2019 liegt das Userbasierte Zeug übrigens unter AppIso sowie den normalen Rules.

 

Tipp: Entfernt man für System und den Firewalldienst die Schreibberechtigung auf die Reg-Folders, werden die Rules nicht mehr erstellt. Hat 'nur' den Caveat oder Vorteil  - Je nach Zweck den man verfolgt -, dass die Apps nicht mehr installiert werden/nicht mehr kommunizieren können weil deren Installation mit einer Exception fehlschlägt (Erstellung der Regeln). Die Regeln werden teilweise auch für die Inner-Host-Kommunikation zwischen den Apps benötigt. Benachrichtigung, Uhrzeit/Datum Popup, Startmenü sind auch solche Apps. Auch das neue Einstellungsmenü. Nicht jedoch Desktop + Taskleiste. Ich mache das gerne für Produktionsmaschinen. 

[kaineanung 14]

vor 15 Stunden schrieb daabm:

 

Was gibt's denn so an Logon-Skripts per GPO? Das klingt sehr nach einem Skript, das hängen bleibt...

 

Habe ich auch gleich gedacht. Aber wenn ich alle GPO (damit meine ich wirklich ALLE) vorrübergehend deaktiviere, sollten die Probleme ja verschwinden. Tun sie aber leider nicht. Somit hängt es nicht an irgendwelchen Scripten bei der Anmeldung bzw. gar nicht an irgendwelchen GPOs.

 

@all

Liege ich damit richtig daß die Warnung mit dem Fehlercode 1534 nichts mit meinem Problem zu tun hat?

 

[daabm 1.366]

Hm - jein... Hast Du direkt nach einem dieser Hänger mal nen GPResult für den aktuellen Benutzer erstellt?

[muenster 16]

Moin,

der Blackscreen scheint eher ein VMWare Problem zu sein.

https://kb.vmware.com/s/article/2034627

 

Manchmal reicht es, wenn es denn geht, die Buildversion vom ESXi auf eine Neuere zu heben (hat hier funktioniert, seit der 6.7 U2 habe ich keinen Blackscreen mehr gesehen (auf 2012R2)).

 

Eventuell hilft's.