phatair

Danke Jan, ich hab mir das Script mal angeschaut und es beinhaltet ja schon eine Vorgabe für Roaming Profiles. Für den ersten Test habe ich mir mal ein Roaming Profile lokal kopiert und mit folgendem PS Befehl versucht das Profil zu migirieren Convert-RoamingProfile -ProfilePath "C:\temp\Test FSLOGIX\test-rdp\" -Target "C:\temp\Test FSLOGIX\" -VHDMaxSizeGB 5 -LogPath 'C:\temp\Test FSLOGIX\log.txt' Hier erhalte ich leider folgende Fehlermeldung im Log "Could not resolve to AD User. Cannot copy." Ich habe mir das Script mal angeschaut, leider bin ich kein Programmierer und so richtig verstehe ich nicht wie er versucht aus dem Pfad/Ordner den AD User zu erkennen. Kennst du vielleicht das Problem bzw. die Lösung? Danke und Gruß, Steffen

Hallo zusammen, wir setzen bei uns aktuell noch 2012R2 RDP Hosts zusammen mit Roaming Profiles ein. Die "temporären" lokalen Profile werden nach einer Abmeldung vom RDP Host gelöscht (per GPO so gesetzt). Nun stellen wir auf 2019 RDP Hosts um und wollen in diesem Zuge auch auf die FSLogix Container umstellen. Soweit ist alle konfiguriert und beim testen ist nun folgendes aufgefallen. Die Container lassen sich zwar per CLI und dem Befehl "frx.exe copy-profile -filename Profile_User.vhdx -username contoso\user -dynamic 1 -verbose" kopieren, aber dazu muss das lokale Profil auf dem RDP Server vorhanden und der User darf nicht angemeldet sein (Es wird wohl der Reg Key aus UserProfile gelesen/übernommen oder so was ähnliches). Nun kann man mit dem Parameter -profile-path= noch den Pfad zum Profil angeben. Dort habe ich dann den UNC Pfad zum Roaming Profile angegeben, aber hier habe ich immer die Fehlermeldung Formatting volume: \\?\Volume{d763ba77-a660-47d9-8e2d-fe2eb0257308}\ Copying profile for user S-1-5-21-602162358-1844237615-839522115-5229 to volume \\?\Volume{d763ba77-a660-47d9-8e2d-fe2eb0257308}\ Error copying profile (0x00000001): Unzulõssige Funktion. Wenn ich das Roaming Profile lokal in einem temporären Ordner kopiere und dann den Befehl ausführe erhalte ich den gleichen Fehler. Hat hier noch jemand eine Idee? Die bestehenden RDP Hosts per GPO so zu konfigurieren, dass das Profil trotz Roaming Profile lokal beim abmelden erhalten bleibt ist erstmal keine Lösung. Da würde ich die Profile auf den neuen Hosts einfach neu anlegen lassen, da wir die wichtigen Ordner wie Desktop, Dokumente usw. sowieso auf das Home Laufwerk umleiten. Danke und Gruß

In der Doku steht dazu nur das und ich bin mir nicht sicher ob ich es so richtig verstanden haben. Ich würde es so interpretieren, da "...When such expiration is detected, password is changed immediately and password expiration is set according to policy" steht. Aber es steht eben nicht explizit da, dass dies auch passiert wenn keine AD Anbindung vorhanden ist. Wie gesagt, einen Test machen wir noch, aber falls mir schon vorher jemand helfen kann habe ich nichts dagegen :) EDIT: Ich denke ich habe das falsch interpretiert. Es scheint eher darum zu gehen, wenn ein Admin Account mit einem längeren Passwort Zeitraum vorhanden ist, wie in den LAPS GPO "Passwort Settings" definiert.

Ich werde es zwar noch mal bei uns testen, aber vielleicht könnt ihr mir trotzdem noch mal auf die Sprünge helfen. Ich verstehe das jetzt so: - ich definiere einen Zeitpunkt, wann das lokale Passwort von der CSE geändert werden soll -> z.B. alter 30 Tage - die CSE generiert ein neues lokale Admin Passwort, wenn dieses Alter erreicht ist und versucht dieses dann in der AD zu speichern - Ist die Speicherung erfolgreich, wird es auf dem Client geändert Das würde für mich bedeuten, wenn z.B. ein Notebook außer Haus ist und die AD nicht erreicht werden kann, wird das Passwort auch nicht geändert. Auch wenn der Zeitpunkt laut Policy schon gegeben ist. Ist dafür die GPO "Do not allow password expiration time longer than required by policy" verantwortlich? Würde ich diese aktivieren, wird das Passwort gesetzt sobald der Zeitpunkt für die Passwort Änderung überschritten ist und es wird nicht geprüft ob die AD erreicht werden kann? Ich werde hier aus der Doku noch nicht ganz schlau. Vielen Dank.

Den Gedanken mit den Notebooks hatte ich auch. Ich hatte gehofft, dass die Geräte, die zu dem Zeitpunkt der geplanten Passwortänderung nicht das AD erreichen können, diese Änderung aufschieben bis sie wieder eine AD Verbindung haben und das neue Passwort übertragen können. Deiner Aussage entnehme ich - dem ist nicht so? :(

Danke Danke! Deinen Post habe ich mir schon vor 2 Jahren angeschaut und Anregungen geholt :) Ich habe auch ein paar sehr gute Beiträge über die AD Absicherung bei Frankysweb.de gefunden. Hier geht es auch um das einrichten von Tiering, PAWs und LAPS. Wenn wir nächste Woche unser AD Audit abgeschlossen haben, werde ich mich mal noch tiefer mit diesen Themen beschäftigen und diese dann bei uns umsetzen. Ein paar Fragen habe ich jetzt schon, aber wenn die nach dem AD Audit noch offen sind werde ich einen neun Thread dazu eröffnen. Danke für eure Hilfe.

Hi Nils, ok, dass klingt dann für mich schon schlüssiger :) Ich werde nach den beiden Schlagworten mal googlen. Die Trennung der Admin Accounts haben wir schon fast komplett durchgezogen. Was uns noch fehlt sind die PAWs. Demnächst haben wir erstmal ein AD Security Audit und da bin ich dann mal gespannt was noch so alles auf uns zukommt (ldap channel binding and ldap signing, usw). Aber das ist ein anderes Thema. Remoteunterstützung oder Telefon ist natürlich klar. Mir ging es vor allem um die grundsätzliche Idee und ob ich diese so wirklich richtig verstanden haben. Es kann natürlich schon dazu führen, dass der Support etwas in die länge gezogen wird und da stellt sich dann die Frage ob Aufwand - Nutzen wirklich so groß ist. Die Trennung, die der Nils erwähnt hat, klingt für mich im ersten Schritt auf jeden fall praxistauglicher :) Gruß, Steffen

Hallo zusammen, ich habe auf dem Born Blog einen interessanten Artikel gelesen, der mich etwas zum nachdenken gebracht hat. https://www.borncity.com/blog/2021/09/11/active-directory-vor-ransomware-attacken-schtzen/ Wir haben vor ein paar Jahren unsere Admin Accounts wie folgt aufgeteilt: - jeder Admin arbeitet an seinem Geräte mit einem normalen AD Account ohne erhöhte Rechte. - für Server Tätigkeiten hat jeder Admin einen eigenen Server Admin. Dieser wird per GPO auf die benötigten Server in die lokale Admin Gruppe eingetragen. So hat nicht jeder Admin auf alle Server zugriff. - für Client Tätigkeiten hat jeder Admin einen eignen Client Admin. Dieser wird ebenso per GPO auf die benötigten Clients in die lokale Admin Gruppe eingetragen. - der lokale Standard Admin auf den Servern ist deaktiviert und ein neuer mit geändertem Namen wurde erstellt. Jeder dieser lokalen Server Admin Accounts hat ein eigenes Passwort (aktuell noch ohne LAPS) Über das Thema hatten wir 2019 hier schon mal diskutiert :) Nun schlägt der Beitrag auf borncity.com ja unteranderem folgende Maßnahme vor: Erstens, muss das lokale Administratorkennwort auf jedem Endpunkt unterschiedlich sein. Microsoft offeriert hierfür eine kostenlose Lösung namens Local Administrator Password Solution (LAPS). Zweitens, sollten keine Domain-Konten in der Gruppe der lokalen Administratoren miteinander verwoben sein, um einen einfachen IT-Support zu ermöglichen. Punkt 1 mit LAPS wollen wir demnächst auch auf den Clients angehen und klingt für mich schlüssig (ich weiß, es gibt noch andere Tools mit denen man das machen kann). Punkt 2 ist für mich im Moment sehr sperrig und hier würde mich mal eure Meinung interessieren. Sicherheit geht meistens mit Komfort Verlust einher, aber das klingt für mich nicht ganz so praxistauglich. Das würde ja bedeuten, dass ich nur noch lokale Admins über LAPS erstelle und damit auch die administrative Tätigkeiten auf den Clients ausführen kann. Bin ich also beim User vor Ort und muss dort erhöhte Rechte anfordern, muss ich irgendwie and das LAPS kommen, sonst kann ich nichts tun. Wie handhabt ihr das bei euch? Ähnlich wie wir - mit getrennten Admin Accounts oder ganz anders? Würde mich interessieren. Vielleicht verstehe ich den obigen Vorschlag auch falsch oder habe einen Denkfehler :) Grüße!

Vielen Dank für eure Antworten. Der Hintergrund, warum wir nicht einfach immer beide Mail Adressen erstellen wollen, ist das unser Mail Gateway die AD Objekte einließt und dort die Attribute "mail und proxyAddresses" ausliest. Nur diese Adressen werden dann auch angenommen. Damit keine Mails von "ungenutzten" Mail Adressen angenommen werden, wollte ich das eben keine unnötigen Einträge in den proxyAddresses erstellt werden. Wird beim erstellen eines Accounts jeweils nachname@firma.de und m.nachname@firma.de erstellt, hätte ich 2 Adressen an die Mails gehen können und das Mail Gateway auch durchlässt. Ich kann aber das Attribute "proxyAddresses" nicht so einfach rausnehmen, da ich mir nicht sicher bin ob die von Exchange Hybrid angelegten Einträge dort vorhanden sein müssen bzw. es vielleicht Einträge gibt die wir durchlassen müssen. UPN, SamAccountName und Name wird ja schon vorher korrekt beim erstellen des AD Objekts gesetzt. Danach wird im Exchange über das bestehende AD Objekt das Mail Postfach erstellt. Lange Rede kurzer Sinn - ich passe die Einträge jetzt einfach manuell an. Ein Script oder ähnliches würde bei unserer Useranzahl keinen Sinn machen bzw. alles nur verkomplizieren. Praktisch wäre es gewesen, wenn der Exchange an Hand der Adressrichtlinie erkennt - oh die Adresse mit nachname@firma.de gibt es schon, also wende ich meine 2. Regel mit m.nachname@firma.de an. Aber halb so wild, wollte nur wissen ob das über die GUI geht oder ich einfach nur zu blöde bin :) Aber was mir beim tippen gerade auffällt. Wenn ich eine neue Adressrichtlinie erstelle, gilt die dann automatisch auch für bestehende Einträge oder nur für neu erstellte Mailboxen? Wenn es nur für neue Mailboxen gilt, wäre es ja ok.

Die Lösung hatte ich auch schon. In einer Mail Adressrichtlinie %s@firma.de %1g.%s@firma.de Dann werden aber für jeden neuen User 2 SMTP Einträge gemacht. Eben nachname@firma.de und m.nachname@firma.de Das möchte ich aber nicht. m.nachname@firma.de soll nur erstellt werden, wenn es nachname@firma.de schon gibt. Daran bin ich dann gescheitert.

Ok, dann lasse ich das mal lieber mit der Änderung :) Grundsätzlich auch kein Problem, das haben wir sogar im Moment so am laufen. Aber ich habe dann das Problem, wenn es die Mail Adresse schon mit dem Nachnamen gibt. Dann müsste er automatisch unsere 2. Lösung nehmen - erster Buchstabe vom Vornamen "." Nachname. Das habe ich über die Mail Adressrichtlinien noch nicht hinbekommen. Mit dem Alias hätte ich halt schon immer gleich die korrekte Standard Mail Adresse erhalten. Die Mail Adressrichtlinie müsste also erkennen - Nachname@firma.de gibt es schon , dann nehme ich m.nachname@firma.de Mit meiner jetzigen Lösung werden immer automatisch beide Adressen angelegt, dass ist natürlich nicht gewünscht :) Falls jemand eine Idee/Lösung hat, wäre ich dankbar.

Hallo zusammen, wir setzen einen Exchange 2016 Server ein und ich möchte unsere E-Mail Adressrichtlinie überarbeiten. Standardmäßig verwenden bei uns alle User als Mail Adresse den Nachnamen. Die Richtlinie dafür ist schnell geschrieben. Nun habe ich aber folgende Frage/Problem. Einige AD User verwenden aber noch ein altes Anmeldenamenschema und verwenden nicht den Nachnamen als Anmeldenamen. Dieser veraltete Anmeldename steht deshalb auch noch im Exchange Alias drin. Kann ich den Exchange Alias einfach in den Nachname ändern, ob macht das Probleme? Der UserPrincipalName oder der SamAccountname ändern sich dadurch ja nicht, richtig? Das dürfte ja der mailNickname in den Attributen sein. Dann könnte ich die Adressrichtlinie auf Alias stellen und die Standard Mail Adresse würde sich dann am Alias orientieren und dieser orientiert sich ja beim erstellen einer neuen Mailbox auch immer am UserPrincipalName. Vielen Dank. Grüße

Vielen Dank euch. Mir ist auch schon aufgefallen, dass die AD Maschinen SID sich zu der lokalen Maschinen SID unterscheidet. Ich war mir nur unsicher, ob es trotzdem irgendwelche Zusammenhänge gibt, die man berücksichtigen sollte. Lokale Accounts haben wir auf den AD Clients nicht (ausgenommen natürlich ein geänderter lokaler Admin Account).

Vielen Dank. Also lag ich mit meinem Gedanken richtig, dass die Computer SID einmalig sein muss, diese aber problemlos mit einem restore auf ein anderes Gerät "übertragen" werden kann. Wichtig ist nur, dass sie nicht doppelt vorhanden ist.

Hallo zusammen, irgendwie stehe ich gerade auf dem Schlauch und hoffe ihr könnt mir helfen. Wir machen von einigen Windows Clients per Veeam Agent wöchentliche Backups. Wenn dieses Backup auf eine andere Hardware zurückgespielt wird und die ursprüngliche Hardware nicht mehr online geht, muss dann die Computer SID per Syspres auf der neuen Hardware geändert werden? Oder ist das egal, da die Computer SID weiterhin einmalig ist und sich nur die Hardware geändert hat? Das Sysprep bei einem Master Image genutzt werden muss, aus dem dann mehrere Clients geimaged werden ist klar. Aber diesen Fall haben wir ja nicht. Da es sich um einen Domänen Client handelt, hätte ich vielleicht nach dem Restore das Gerät noch mal aus der Domäne genommen und dann noch mal sauber aufgenommen, um mögliche AD Probleme auszuschließen. Für eine Rückmeldung wäre ich sehr dankbar. Gruß

Die Probleme gehen weiter... https://www.bleepingcomputer.com/news/microsoft/new-windows-print-spooler-zero-day-exploitable-via-remote-print-servers/ Wir haben dazu folgende GPO gesetzt, wie im Artikel empfohlen https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.Printing::PackagePointAndPrintServerList_Win7&Language=de-de Falls man schon in der GPO "Point-and-Print-Einschränkungen" die Verbindung zu den entsprechenden Servern eingeschränkt hat, muss die oben genannte GPO trotzdem gesetzt werden!

Die hatten wir vorher komplett vom Client gelöscht (Client Druckserver, Tab Treiber). Ebenso haben wir es auf einem neuen geimaged Gerät getestet.

Also bei uns ist das Update jetzt auf gut 80 Clients (Win 10 20H2) installiert und es gab bis jetzt keine Probleme. Ebenso ist es auf den Printservern (2019 und 2012R2) installiert. Spooler ist auf allen Servern deaktiviert (Ausnahme Print Server und Terminalserver) Da auf den Print und Terminalservern das Update installiert wurde und keine Print-and-Point Einschränkung greift, sind diese "sicher". Wir haben die Point-and-Print Einschränkung in der GPO für die Clients auf aktiviert gesetzt und haben die UAC Meldung aktiviert. Tests haben ergeben, dass die Treiber auch so ohne User Interaktion installiert werden können. Vorher waren die Meldungen unterbunden und das führte dann ja dazu, dass die Sicherheitslücke nicht sauber geschlossen wurde. bzw. weiter ausgenutzt werden konnte und die Einstellung sowieso unsicher ist. Da wurde wohl eine Altlast mitgeschleppt, die gar nicht mehr benötigt wurde. Hat sich das Ganze Theater ja doch gelohnt :) Für alle Clients wurde ebenso per GPO der Remote Zugriff auf den Spooler deaktiviert Ich hoffe ich habe nun nichts übersehen und wir müssten somit gut geschützt sein. Hilfreich war wie gesagt dieses Diagramm Viel Erfolg beim patchen/konfigurieren :)

Was genau meinst du damit? Reicht es aus, wenn sie digital signiert sind? Es ist ja definitiv keine Lösung, dass eine UAC erscheint und administrative Rechte benötigt werden, wenn der User einen Drucker verbinden möchte. Entweder müssen wir den Treiber dann zentral verteilen oder aber eben die "richtigen" Treiber verwenden. Wir haben ja auf allen Servern den Print Spooler Dienst beendet/deaktiviert auf denen er nicht benötigt wird. Einzig auf den Terminalservern und Print Servern + Clients läuft dieser noch. Auf den Terminalservern konnten wir die ACL nicht anpassen, da danach keiner mehr drucken konnte (hie rmüssen wir noch prüfen ob es ein grundsätliches Problem ist oder ein Fehler bei der Konfig gemacht wurde). Aber die ACL Methode ist ja auch etwas umstritten. Ebenso haben wir auf der Firewall zwischen den Server und Client VLANs IPS aktiviert. Das schützt zumindest die Kommunikation zwischen den Bereichen. Wir werden jetzt mal testen, ob wir die Print-and-Point Einschränkung rausnehmen können, ohne das die User erhöhte Berechtigungen für die Drucker Installation benötigen.

Hallo zusammen, also ich bin langsam auch etwas verwirrt was die ganzen Infos angeht. Wir haben im Moment auf allen Member Servern den Print Spooler deaktiviert. Auf den Print Servern haben wir die ACL angepasst. Auf den Clients/RDP Servern haben wir die GPO konfiguriert, dass die Clients keine Remote Anfragen für den Spooler Dienst annehmen Aktuell haben wir aber die Point-and-Print Einschränkung aktiviert, damit die Clients die Drucker ohne Meldung installieren können. Wir haben diese GPO an alle Clients und RDP Server verteilt (sonst keine Server) und die Option "Benutzer können Print-und-Point Einschränkung nur mit folgenden Servern verwenden" aktiviert und unsere Print Server angegeben. Nun könnten wir die GPO deaktivieren und die Universal Druckertreiber zentral verteilen. Damit könnten die User die Drucker ohne Meldung installieren (da Treiber schon vorhanden) und unsere Umgebung soweit gesichert - verstehe ich das richtig? Oder aber wir belassen es so wie es ist und aktivieren auf den Druckservern die neuen Reg Keys für "RestrictDriverInstallationToAdministrators". Nur verstehe ich noch nicht wirklich, dass dieser Reg Key macht? Mit dem Wert 1 für den Key kann ja nur noch der Admin Treiber auf dem jeweiligen Server installieren und es werden die Point-and-Print Einstellungen aus der GPO überschreiben. Wenn, wie bei uns, die Point-and-Print Einstellungen aber gar nicht für die Server gelten, dann hat sich das Thema ja sowieso erledigt und der Server ist sowieso schon geschützt, wenn der aktuelle Patch installiert ist, da der Patch ja nur nicht schützt wenn die Point-and-Print Einschränkung gesetzt ist. Verstehe ich das richtig? Schönen Abend noch Beste Grüße Edit: Laut diesem Diagramm (https://www.kb.cert.org/vuls/id/383432) wären die clients wohl lokal angreifbar, wenn wir es so belassen wie es jetzt ist und den Patch installiert haben. Müssen und wohl mal Gedanken über das Verteilen der Drucker Treiber machen, um die point-and-print Einschränkungen (Meldungen) wieder auf default zu setzen. Wenn ich es richtig verstehe, ist eine User Installation eines Drucker Treibers nicht mehr möglich, wenn man die Schwachstelle sauber schließen möchte (Stand jetzt).

Hat wunderbar funktioniert. Nu kommt beim gpupdate keine Meldung. Wenn ich auf anderen PCs die gleiche Fehlermeldung habe, werde ich einfach mal versuchen die GPT.INI auszutauschen. Dann könnte ich das nämlich automatisiert verteilen. Vielen Dank.

Hi Martin super, danke. Eine Frage noch. Warum erhöhe ich die Versionsnummer genau um 65537? Hat das irgendeinen Hintergrund? Gruß, Steffen

Ok, ich drücke mich immer etwas unglücklich aus - Sorry! Ich meinte, bei den Domain GPOs liegen die GPOs ja im Sysvol\fqdn\Policies Verzeichnis. Dort liegen dann die Ordner mit den entsprechenden GUIDs und darunter dann immer die Verzeichnisse Machine, User, Group Policy und die GPT.ini Wenn wir jetzt nur Domain GPOs verwenden, dürfte ja unter C:\Windows\System32\GroupPolicy\ nichts liegen. Die Verzeichnisse "C:\Windows\System32\GroupPolicy\Machine" und "C:\Windows\System32\GroupPolicy\User" sind ja auch leer. Aber der Ordner "C:\Windows\System32\GroupPolicy\DataStore\0\sysvol\<unser FQDN>\Policies" eben nicht. Dort liegen Ordner mit GUIDs die ich nicht kenne. Daher die Frage ob Windows hier per Default irgendwas erstellt. Das hat jetzt natürlich nichts direkt mit der Disk Quota Problematik zu tun, ist mir aber aufgefallen und wollte nur wissen ob dieser Ordner dort überhaupt sein sollte, wenn wir nur Domain GPOs verwenden. Die andere Frage ist eben, ob ich die GPT.ini unter "C:\Windows\System32\GroupPolicy\" einfach anpassen und für alle Clients verteilen kann. Auf allen Clients sind keine lokalen GPOs definiert. Ich würde dann aus dieser GPT.ini den Eintrag {3610eda5-77ef-11d2-8dc5-00c04fa31a66} löschen und dann verteilen. Oder kann diese GPT.ini einfach komplett gelöscht werden, wenn keine lokalen GPOs verwendet werden? In der GPT.ini steht folgendes [General] displayName=Neues Gruppenrichtlinienobjekt gPCFunctionalityVersion=2 gPCMachineExtensionNames=[{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957D-509E-11D1-A7CC-0000F87571E3}{3D271CFC-2BC6-4AC2-B633-3BDFF5BDAB2A}][{3610EDA5-77EF-11D2-8DC5-00C04FA31A66}{0F6B957D-509E-11D1-A7CC-0000F87571E3}][{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B6664F-4972-11D1-A7CA-0000F87571E3}][{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}] Version=1048595 gPCUserExtensionNames=[{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}][{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B66650-4972-11D1-A7CA-0000F87571E3}][{A2E30F80-D7DE-11D2-BBDE-00C04F86AE3B}{FC715823-C5FB-11D1-9EEF-00A0C90347FF}]

Hi Martin, vielen Dank für den Hinweis. Das stimmt natürlich, die lokale GPO setzt nur die RegKeys. Unter C:\Windows\System32\GroupPolicy finde ich eine GPT.ini und dort ist tatsächlich den Wert {3610eda5-77ef-11d2-8dc5-00c04fa31a66} enthalten. In den Ordnern "C:\Windows\System32\GroupPolicy\Machine" und "C:\Windows\System32\GroupPolicy\User" liegen nur leere Ordner und sonst nichts. Es gibt aber noch den Ordner "C:\Windows\System32\GroupPolicy\DataStore\0\sysvol\<unser FQDN>\Policies Dort liegen mehrere Ordner mit unbekannten IDs z.B. {9D9D2DCB-CA6C-4193-89D9-5A341FA15FF0} und in diesen Ordner liegen dann noch mal jeweils GPT.ini Dateien und ein Ordner Machine. In diesem Machine Ordner liegen dann unterschiedliche Dateien/Ordner. Alle haben das gleiche Datum vom November 2019. Weißt du, ob das einfach default Dateien sind? Wir nutzen für unsere GPOs einen central Store und verwenden nirgends lokale GPOs Da wir diese Fehlermeldung beim gpupdate auf allen Clients haben, kann ich die lokale gpt.ini einmal anpassen und diese dann für alle Clients verteilen?

Hallo zusammen, wir erhalten auf unseren AD Geräten bei einem gpupdate immer die Fehlermeldung Fehler beim Anwenden der "Microsoft Disk Quota"-Einstellungen. Die "Microsoft Disk Quota"-Einstellungen besitzen möglicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen". Google hat mir hier schon einige Lösungen gezeigt. Vor allem diesen MS Beitrag https://docs.microsoft.com/de-de/archive/blogs/core/event-id-1085-source-grouppolicy-windows-failed-to-apply-the-microsoft-disk-quota-settings-resolved Dort wird gesagt, dass in einer GPO Disk Quota mal konfiguriert war oder noch konfiguriert ist. Das dann ein Attribut gelöscht werden muss. Ich habe alle GPOs geprüft, dieses Attribut ist in keiner unserer GPOs gesetzt, auch nicht in der DefaultDomainSettings GPO. Wenn ich ein gpresult ausführe, sehe ich, dass der Eintrag von der lokalen Richtlinie kommt (LocalGPO) - Siehe angehängten Screenshot. In dem Regedit Pfad \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\ finde ich dann auch das im oberen Link genannten Attribut mit dem Wert {3610eda5-77ef-11d2-8dc5-00c04fa31a66} Es wird also durch die lokale GPO die Disk Quota genutzt und deshalb die Warnung. Wir verwenden diese aber auf den PCs nicht. Kann ich den RegKey einfach löschen oder muss ich per Domain GPO die lokale GPO irgendwie mit den korrekten Werten überschreiben? Ich möchte ja einfach nur, dass diese Disk Quota nicht mehr genutzt wird und die Fehlermeldung beim gpupdate verschwindet Für einen Tipp wäre ich sehr dankbar. Gruß