Server 2012 R2, Kontingentverwaltung aufheben

[andrew 15]

hello together

 

Nachfolgend eine Problemstellung in meiner Testumgebung

 

Problem: per GPO auf der OU Server eine Richtlinie definiert, welche folgende Einstellungen beinhaltet

=> Kontingentverwaltung aktivieren

=> Speicherplatz bei Überschreitung der Kontingentgrenze verweigern

=> Speicherplatz begrenzen auf 5 GB

=> Warnstufe festlegen auf 10 GB

 

angewendet auf LW C:\ und D:\

 

Datenträgerverwaltung auf Hyper-V Server sagt beispielsweise folgendes

=> Kapazität auf LW C:\ ist 5 GB

=> freier Speicher auf LW C:\ ist 0 GB

 

=> Kapazität auf LW D:\ ist 5 GB

=> freier Speicher auf LW D:\ ist 4.98 GB

 

Nun, in dieser OU war auch der Hyper-V Server, welcher die VMs lokal auf der Festplatte D:\ beinhaltet

 

Das Problem ist nun, dass ich bis jetzt noch keinen Weg gefunden habe, um diese, anscheinend noch immer greifende GPO deaktivieren, löschen oder entfernen zu können.

 

Wenn ich zum Beispiel eine neue GPO erstelle (die alte hatte ich gelösche, als ich merkte, dass ich hierbei einen Denkfehler gemacht habe) Und: die Kontingentverwaltung explizit deaktiviere, mich auf den Server 2012 R2 Core Server mit Mini Grafik GUI per RDP verbinde und im DOS Fenster gpupdate /force ausführe, interessiert es diesen Server als Beispiel nicht wirklich.

 

In den Reigistry Einstellungen ist die Kontigentverwaltung immer noch mit den Daten der damals gesetzten GPO vorhanden.

Frage: Wie bringe ich den Hyper-V Server als Beispiel dazu, dass er wieder seine physikalischen Speicherwerte der Harddisk ermittelt und auch verwendet und sich nicht mehr an der künstlich, erzeugten Kontingentverwaltung orientiert?

 

Gibt es keine Möglichkeit, remote via PowerShell oder ähnliches diese Kontingentverwaltung aufzuheben?

Habe auch versucht, die Berechtigungen in der Registry auf dem Schlüssel DiskQuota für den Benutzer System von Schreibrechten in Leserechte einzugrenzen (zuvor natürlich in diesem Schlüssel die Kontingentverwaltung auf deaktiviert gesetzt), jedoch war beim Neustart wieder die alte Registry Einstellung aktiv.

 

Wie diese wieder gesetzt werden konnte, verstehe ich nicht, weil ich zurzeit keine, aktuelle GPO mehr auf dieses Computer Objekt anwende, welches diese falschen Werte für Laufwerk C:\ und D:\ setzt?!

[Sunny61 773]

Ich arbeite an dieser Stelle gerne mit Sicherheitsgruppen. Server1 - Server10 rein und diese Gruppe als Sicherheitsfilter im GPO verwenden. Alternativ eine UnterOU anlegen und die Server die es betreffen soll dort hineinschieben und das GPO auf die UnterOU verlinken.

 

Besser wäre es vielleicht gewesen, Du hättest das GPO nicht gelöscht, sondern alles auf nicht konfiguriert gestellt und ein gpupdate /force auf dem Hyper-V ausgeführt. Zusätzlich neu starten.

Oder den Hyper-V einfach im AD verschieben, so dass er nicht mehr im Verwaltungsbereich des GPO liegt.

[andrew 15]

Die Idee mit den Sicherheitsgruppen finde ich gut, werde ich zukünftig auch so anwenden.

Genau, das GPO Objekt hätte ich nicht löschen sollen, nun ist es doch geschehen ..

 

Ja, das Computer Objekt für den Hyper-V Server habe ich mittlerweile auch verschoben, jedoch ist die GPO Richtlinien anscheinend immer noch aktiv Und: Das falsch konfigurierte Kontingent wirkt blöderweise immer noch auf die Laufwerke C:\ + D:\ ..

 

Wollte auf dem Server 2012 Core mit Minimal Grafik GUI die vollwertige, grafische Oberfläche installieren, jedoch habe ich nun das Problem, dass er dies nicht zulässt, anscheinend, weil zu wenig Speicher auf Laufwerk C:\ ...konkret ist ja dieser zurzeit künstlich auf 0 MB gesunken...

 

Es muss doch eine Möglichkeit geben, die Registry, den Wert dort zu deaktivieren Und: die Berechtigungen so setzen zu lassen, dass der System Benutzer keine Rechte mehr hat, selber, nach einem Neustart den Wert für Datenträgerkontingent auf 1 zu setzen, was ja diesen aktvieren würde oder eben immer noch aktiviert lässt - ich staune ...Es kann ja doch nicht wahr sein, dass man durch eine solche Fehlkonfiguration (Server 2012 Core Minimal GUI, das ist ja nochmals das blöde daran, so nun in den Möglichkeiten zur Rettung nochmals eingeschränkt) dann dieses immer noch wirkende GPO Objekt, welches nicht mehr existiert, nicht mehr losbringt?

 

Auch wenn ich neue GPO definieren, diese wieder auf das Computer Objekt Hyper-V anwende, wie ich schon erwähnt habe, das interessiert den Server nicht im geringsten?

Ob die GPO nicht angewendet werden kann, weil 0 MB freier Speicher auf Laufwerk C:\ ist, weiss ich nicht ..es scheint so zu sein?! ...gpresult /r funktioniert auf dem Core auch nicht?! (Zugriff verweigert)

[Sunny61 773]

Da es ja eine Testumgebung ist, plattmachen und neu anfangen. Oder ist die Testumgebung schon live?

Du kannst versuchen herauszufinden, welche Registryeinstellungen das verursachen, die dann manuell löschen. Dazu brauchst du möglicherweise eine weitere 'Testumgebung'.

[andrew 15]

ich kenne die Registry Einträge ganz genau, habe es vorerst nicht mit löschen versucht, sondern mit Berechtigungen anpassen, indem ich für den System Benutzer auf dem betreffenden Registry Schlüssel die Berechtigungen von Änderungsrechten auf Leseberechtigungen abgeändert hatte.

 

Nur, nach einem Neustart hatte der System Benutzer auf dem von mir geänderten Registry Schlüssel wieder Schreibrechte, das Kontingent war wir auf aktiviert (Wert 1, 0 wäre deaktiviert)

Versuche mal, heute den Schlüssel zu löschen, viel geht nicht verloren, nur die sowieso von mir nicht mehr, falsch konfigurierte Kontingenten Verwaltung :-)

 

NEWS folgen heute Abend.

Meine Testumgebung ist so zu sagen meine private, produktive Umgebung :-)

[Reingucker 3]

Haste mal probiert die GPO direkt aus der Reg vom Server zu löschen? Wenn die da weg ist dann wirkt die auch nicht mehr.

[Sunny61 773]

Meine Testumgebung ist so zu sagen meine private, produktive Umgebung :-)

Schlecht, ganz schlecht. Aber das weißt Du sicherlich.

[andrew 15]

habe bei einer VM Maschine, auf welche auch diese bereits gelöschte GPO wirkte Und: welche nun das gleiche Problem hat wie der Hyper-V Server, folgende Erkenntnis gewonnen:

- GPO Policie via Registry löschen war möglich, nach Neustart konnte ich auf diesem virtuellen Server dann via Windows Explorer, rechte Maustaste, Reiter Kontigent einfach die Hacken rausnehmen (die Einstellungen waren alle noch präsent, aber nicht mehr durch die aktive Policy Richtlinie eingegraut)

 

Nachdem ich so nun die Möglichkeit hatte, händisch das Kontingent zu deaktivieren (via Windows Explorer), zeigte die Datenträgerverwaltung für Laufwerk C:\ auch gleich wieder den effektiven, noch verfügbaren Speicherplatz an (ca. 50GB)

 

Beim Hyper-V Server könnte ich gleich vorgehen, wenn dieser die volle, grafische Oberfläche zur Verfügung hätte, ist aber nicht der Fall, da Core Sever mit Minimal Grafik GUI, darum weiss ich nach wie vor nicht, wie ich hier das Problem lösen soll?

 

Der Vorschlag vom Platt machen möchte ich erst umsetzen, wenn ich weiss, dass es keine Möglichkeit gibt, das Kontingent aufzuheben (auf Laufwerk C:\)

Wäre eigentlich schon verrückt, wenn es für diese Situation keine technische Möglichkeit gäben würde, das Kontingent mit PowerShell oder was weiss ich aufzuheben??!!

[Reingucker 3]

 

- GPO Policie via Registry löschen war möglich, nach Neustart konnte ich auf diesem virtuellen Server dann via Windows Explorer, rechte Maustaste, Reiter Kontigent einfach die Hacken rausnehmen (die Einstellungen waren alle noch präsent, aber nicht mehr durch die aktive Policy Richtlinie eingegraut)

 

Ja, hatte bei mir damals auch geklappt. Jetzt wird die GPO nicht mehr aufgerufen, ist aber noch im Sysvolordener. Die macht da zwar nix mehr und es wird da auch keine zweite mit der gleichen GUID geben die da kollidieren könnte (außer der RID stolpert...), aber da auch noch rauslöschen macht das ganze dann sauber und schick. Einfach nach der GUID von der GPO im sysvol [edit] auf dem Server unter Windows/sysvol suchen und löschen.

 

Und mit regedit kannst du in der Konsole den eintrag in der reg löschen.

 

https://technet.microsoft.com/de-de/library/cc742145%28v=ws.10%29.aspx

 

Am Besten erst mal den ganzen Grouppolicyschlüssel exportieren damit du die genaue Struktur siehst

 

http://support.microsoft.com/en-us/kb/168589

 

und dann gezielt den störenden gpo-Eintrag löschen.

 

Edit:

 

Hier sollten die zu finden sein

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State

bearbeitet 25. März 2015 von Reingucker

[daabm 1.199]

außer der RID stolpert...

Was hat denn ein RID mit einer GUID zu tun?

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State

Knapp vorbei:

HKLM|HKCU\Software\Policies und

HKLM|HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

enthalten die Einstellungen aus GPOs.

 

Der von Dir genannte Schlüssel enthält "Verwaltungsdaten" zur Verarbeitungshistorie (wie z.B. die jeweilige GPO-Version etc.)

[Reingucker 3]

Was hat denn ein RID mit einer GUID zu tun?

 

Na, die GPO hat eine GUID. [edit] Und die vergibt der RID. Und mit der steht sie in der reg und im der sysvol.

 

 

Knapp vorbei:

HKLM|HKCU\Software\Policies und

HKLM|HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

enthalten die Einstellungen aus GPOs.

 

Der von Dir genannte Schlüssel enthält "Verwaltungsdaten" zur Verarbeitungshistorie (wie z.B. die jeweilige GPO-Version etc.)

 

Also wenn ich die GUID einer GPO bei mir in Regedit zum suchen eingebe, dann komme ich im Grouppolicyschlüssel raus. Und dort ist auch der Verweis drin auf die GPO im sysvol.

 

Edit:

 

Hm, bisher war ich der Meinung dass die RID nicht nur bei der Bildung der SID, sondern auch bei der Bildung der GUID mit benutzt wird - wenn auch in einer anderen Weise. Bin mir aber nach deiner Fragestellung nicht mehr so sicher.

 

Ich finde aber jetzt auch nichts darüber wie genau eine GUID erstellt wird. Nur per Zufallsprogramm kanns eigentlich nicht sein, denn dann reichen die 128 bit mMn nicht um Global eindeutg zu sein.

 

Wer einen Link hat der GENAU erklärt WIE die GUID erstellt wird, bitte posten.

 

Edit2:

 

"Bei der Erzeugung neuer GUIDs werden unter anderem die aktuelle Zeit, die Seriennummer der Netzwerkkarte und/oder andere zahlreiche Parameter berücksichtigt."

 

Tja, sieht so aus als wenn da jeder in seine Function etwas anderes als Parameter einbaut - Hauptsache das Endformat stimmt.

bearbeitet 25. März 2015 von Reingucker

[andrew 15]

In der Registry fand ich auf dem oder den betroffenen Maschinen nur am folgenden Ort die Einstellung der GPO, welche anscheinend immer noch registry technisch gewirkt hat, dies, obwohl das AD Objekt bereits nicht mehr gegriffen hat (war via gpresult /r nicht erschienen)

 

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\

 

gpresult /r konnte ich aber nur auf Member Server ausführen, welche ein vollwärtiges GUI haben, auf Core Server funktioniert gpresult /r NICHT!

 

Rückblick, Kurzabriss der Problemstellung

Hatte ein Gruppenrichtlinien Objekt, welches eine Quota auf LW C:\ und LW D:\ gesetzt hatte.

 

=> Speicherplatz bei Überschreitung der Kontingentgrenze verweigern

=> Speicherplatz begrenzen auf 5 GB

=> Warnstufe festlegen auf 10 GB

=> Richtlinie auf eine OU angewendet, in welcher ALLE Member Server enthalten waren, blöderweise auch der Hyper-V Server :-)

 

Warum blöderweise?

Weil mir dieser plötzlich in der Computerverwaltung bzw. in der Datenträgerverwaltung bei Laufwerk C:\ 0 MB angezeigt hat.

 

Laufwerk D:\ war auch entsprechend eingeschränkt, darauf sind aber lokal gespeichert meine virtuellen Maschinen.

Zur Erinnerung: Meine Umgebung ist eine Testumgebung Und: wird auch von mir "produktiv" genutzt. Ja, ich weiss, eine Testumgebung produktiv nutzen ist nicht unbedingt das gelbe vom Ei :-)

Mein Hyper-V Server ist ein Server 2012R2 Core mit Minimal Interface GUI

Diese Tatsache hat mir in Bezug auf die Problemlösung nicht unbedingt geholfen, sondern mir die Sache erschwert, ist aber nur eine Randbemerkung.

 

Das Problem konnte ich soweit lösen, indem ich via CMD Fenster auf dem Hyper-V Core Server folgenden Befehl verwendet habe:

Zuerst habe ich eine Abfrage gestartet, eine Abfrage mit dem Befehlszeilentool fsutil. Mit diesem kann man Quotas verwalten, setzen, deaktivieren usw.

=> fsutil quota query c: bzw. fsutil quoty query d:

 

Danach habe ich die mir angezeigte, noch immer wirkende Quota deaktiviert, wie folgt

=> fsutil quota disable C: bzw. fsutil quota disable D:

 

Diesen Befehle habe ich übrigens gleich auf allen Member Servern angewendet, welche zum Teil immer noch Quotas aufwiesen und auch auf LW C:\ teils kein einziges Bit mehr frei hatten.

Das Tool fsutil hat mir in diesem Fall also geholfen :-)

[Reingucker 3]

In der Registry fand ich auf dem oder den betroffenen Maschinen nur am folgenden Ort die Einstellung der GPO, welche anscheinend immer noch registry technisch gewirkt hat, dies, obwohl das AD Objekt bereits nicht mehr gegriffen hat (war via gpresult /r nicht erschienen)

 

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\

Interessant.

 

 

=> fsutil quota query c: bzw. fsutil quoty query d:

 

Danach habe ich die mir angezeigte, noch immer wirkende Quota deaktiviert, wie folgt

=> fsutil quota disable C: bzw. fsutil quota disable D:

 

Diesen Befehle habe ich übrigens gleich auf allen Member Servern angewendet, welche zum Teil immer noch Quotas aufwiesen und auch auf LW C:\ teils kein einziges Bit mehr frei hatten.

Das Tool fsutil hat mir in diesem Fall also geholfen :-)

 

Interessant und gut.