RDS 2008 R2 bei Benutzeranmeldungen erscheint die Fehlermeldungen „Nicht genügend Systemressourcen, um den angeforderten Dienst auszuführen.“ im Ereignislog (EventID: 1502, 1508)

stellen wir uns folgendes Szenario vor:

Bei dem Kunden läuft ein seit Jahren ein RDS-Server welcher nun plötzlich im Ereignislog zu Benutzeranmeldungen mehrere Fehler protokoliert und der Benutzer nur ein Temporäres Profil erhält.

Folgende EventIDs:

1508: Die Registrierung konnte nicht geladen werden. Dieses Problem wird oft durch zu wenig Arbeitsspeicher oder nicht
ausreichende Sicherheitsberechtigungen verursacht.
Details - Nicht genügend Systemressourcen, um den angeforderten Dienst auszuführen.
for C:\Users\username\ntuser.dat

1508: Die Registrierung konnte nicht geladen werden. Dieses Problem wird oft durch zu wenig Arbeitsspeicher oder nicht
ausreichende Sicherheitsberechtigungen verursacht.
Details - Nicht genügend Systemressourcen, um den angeforderten Dienst auszuführen.
for C:\Users\username\AppData\Local\Microsoft\Windows\\UsrClass.dat

1502: Das lokal gespeicherte Profil kann nicht geladen werden. Mögliche Fehlerursachen sind nicht ausreichende
Sicherheitsrechte oder ein beschädigtes lokales Profil.
Details - Nicht genügend Systemressourcen, um den angeforderten Dienst auszuführen.

Diese Fehler können mehrere Ursachen haben, was die Fehlersuche erschwert.

An den zu knapp bemessenen Systemressourcen (CPU, RAM) des RDS-Servers konnte es in unserem Fall nicht liegen, die Ursache muss also wo anders liegen.

Schnell hatte ich eventuell Druckertreiber und die Registry als mögliche Fehlerquelle in Verdacht. Nach etwas Recherche stellte sich heraus, das die Größe der Registry, im besonderen des Zweiges „HKEY_USERS\.DEFAULT“ das Problem sein könnte. Siehe dazu:

https://support.microsoft.com/en-us/help/2871131/the-size-of-the-hkey-users–default-registry-hive-continuously-increas

Die Daten des Zweiges „HKEY_USERS\“ liegen im Dateisystem von Windows im Ordner: „C:\windows\system32\config“. Ein kurzer Größencheck des Ordners bestätigte die Vermutung.

Die Daten nahmen mehr als 2 GB ein. Der Grund für diese problematische Größe liegt an Einträgen von Druckertreibern, welche entweder nicht gelöscht wurden und die Registry weiter anwachsen lies. Dieses Problem wurde durch einen Microsoftupdate zwar behoben. Da die Registry sich aber wie eine Datenbank verhält und selbst wenn die Einträge gelöscht wurden sich die Größe sich nicht verringert, sondern nur der Speicherplatz in der Datenbank freigeben wird.

Um dies weiter zu verifizieren startete ich den Performance Monitor auf dem Server und lasse mir die prozentuale Auslastung der Registry anzeigen:

Wie zu sehen, ist die Auslastung nahezu bei 100%. Um das Ganze gegen zu checken habe ich das gleiche nochmal auf einem RDS-Server durchgeführt der keine solche Problem hat. Und siehe da: Die Auslastung liegt dort nur bei ca. 15%.

Also, wie nun die Registry wieder auf eine funktionale Größe bekommen?

Microsoft empfiehlt für das Problem die Registry zu komprimieren.

Siehe: https://support.microsoft.com/en-us/help/2498915/how-to-compress-bloated-registry-hives

Kurzbeschreibung. Komprimierung einer aufgeblasenen Registry:

1) Boot from a WinPE disk.
2) Open regedit while booted in WinPe, load the bloated hive under HLKM. (e.g. HKLM\Bloated)
3) Once the bloated hive has been loaded, export the loaded hive as a "Registry Hive" file with a unique name.
4) Unload the bloated hive from regedit.
5) Rename the hives so that you will boot with the compressed hive.
e.g.
c:\windows\system32\config\ren software software.old
c:\windows\system32\config\ren compressedhive software

Nach weiterer Recherche fand ich ein Tool welches die Schritte für uns übernimmt. Das Freewaretool namens „Registry Compressor“. Dieses Tool checkt den Betroffenen Registryzweig und zeigt uns nach der Analyse an welche Große sich einsparen lässt.

Das Tool automatisiert die Punkte, welche MS im Artikel „Komprimierung einer aufgeblasenen Registry „ händisch“ durchführt. Sicherheitshalber machte ich einen Snapshot der VM. Nach dem anstehenden Neustart zeigt sich nach einem Blick in den Performancemonitor schnell das das Problem behoben wurde. Dies Auslastung ist wieder auf einem „normalen“ Level.

Die Fehlermeldungen sind danach im Ereignislog nicht mehr aufgetaucht und die Benutzer hatten auch keine Probleme mehr mit temporären Profilen.

Quelllinks: