phatair
-
Gesamte Inhalte
505 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von phatair
-
-
Am 5.10.2023 um 10:10 schrieb Sunny61:
BTW: Es reicht ein gpupdate /target:computer ganz sicher aus. ;)
Es ist in der Tat so, man muss ein gpupdate /force machen. Ein gpupdate /target:computer reicht leider nicht (wie von NorbertFE schon vermutet).
Wir sind immer noch auf der Suche nach der Ursache. Aber der Support von ZenWorks meinte auch, dass es möglicherweise am Client liegen könnte.
-
Guten Morgen,
bei dem Punkt mit dem MS Update Health Tool hatte ich einen Denkfehler.
Das Tool wurde installiert, da der Client davor seine Verbindung zum WSUS verloren hatte. Das Tool war also nicht der Grund für das Problem sondern eher das Resultat.
Ich habe nun mal geprüft auf wievielen Clients dieses Tool installiert wurde. Es ist auf 10 von 200 Clients vorhanden. Es betrifft (aktuell) also nur eine kleine Anzahl von Clients.
Hier habe ich auch einen identisches Problem bei MS gefunden
Ich prüfe nun, ob es an unserem neuen ZCM Agent liegen könnte. Der bietet auch ein Patch Management, welches wir aber nur für Third Party Software nutzen und nicht für MS Updates,
Ich werde nun erstmal auf den betroffenen Clients die Software wieder deinstallieren.
Ebenso werde ich über ZCM ein Bundle laufen lassen, welches prüft ob der RegKey vorhanden ist. Wenn nein, wird ein gpupdate /force ausgeführt.
So ist zumindest aktuell mal sichergestellt, dass alle Clients welche die WSUS Verbindung verloren haben, auch wieder angebunden werden.
Falls ich den Grund für das Problem finde, werde ich den Beitrag hier aktualisieren.
-
2
-
-
vor 3 Minuten schrieb zahni:
Vielleicht hat der lokale Anwender zu viele Rechte?
Die Lösung wäre zumindest nachvollziehbar :) Aber nein, bei uns hat kein User lokale Adminrechte.
vor 25 Minuten schrieb NorbertFe:Das ist ja jetzt so ein Ausnahmefall, ansonsten würden die ja nicht verschwinden. Heißt, deine GPOs funktionieren korrekt und du musst jetzt den Grund finden, der den entsprechenden Registry-Bereich leert.
Bye
Norbert
Ich habe gerade mal im Eventlog nachgeschaut. An dem Tag, seit dem sie sich am WSUS nicht mehr gemeldet haben, wurde microsoft update health tools installiert.
Das ist bei 2 Clients identisch, bei denen wir heute festgestellt haben, dass die GPO Einträge fehlen.
Nun muss ich mal schauen woher dieses komische MS Tool kommt. Das ist nichts was wir verteilen.
Vielleicht ist das ein Ansatz.
-
Hallo zusammen,
wir haben aktuell folgendes sporadisches Problem.
Auf einigen Windows 10 22H2 (10.0.19045.3448) Clients fehlen plötzlich die WSUS GPO Einträge bzw. der komplette Schlüssel in der Registry -> "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
Damit greifen die Clients auf Windows Update zu und es wird z.B. auch das Windows 11 Update beworben.
Im WSUS stehen die Clients dann auch "Client hat sich seit x Tagen nicht mehr gemeldet" drin.
Prüft man per gpresult /r die GPOs auf dem Client, ist die GPO aber noch zugewiesen.
Ebenso zeigt gpresult /h <pfad> auf dem Client an, dass die WSUS GPO übernommen wurde
Prüft man aber eben den Regpfad, fehlt der komplette WindowsUpdate Ordner/Schlüssel.
Führt man ein gpupdate /force durch, wird der Regestry Eintrag wieder gesetzt und alles funktioniert wie es soll. Wie man ja aber bei Gruppenrichtlininen.de gelernt hat, soll man force nur im Ausnahmefall nutzen :)
Ich verstehe nicht, warum plötzlich bei einigen Clients dieser Eintrag nicht mehr per GPO gesetzt wird bzw. verschwindet.
Hat hier jemand eine Idee?
Vielen Dank.
Grüße,
Steffen
-
vor 2 Stunden schrieb cj_berlin:
Moin,
was ist denn mit der Public Folder *Mailbox*, wo der Ordner lebt? Vielleicht ist diese voll bzw. gegen Quota gelaufen?
Das wars tatsächlich. Hatte ich null auf dem Schirm, dass hinter dem Public Folder ja noch eine Mailbox steht die auch eine Quota hat.
Nach der Anpassung habe ich noch den Information Store Dienst neu gestartet und dann ging es sofort.
Vielen Dank für eure Hilfe.
-
2
-
-
vor 5 Stunden schrieb Nobbyaushb:
Es gibt keinen Exchange 2022!
Du könntest einfach mal die Bereitstellung vom Information-Store aufheben und neu anbinden
Merkt keiner und kann während der Arbeitszeit erfolgen
Leider hat beides nicht geholfen, weder Information-Store aufheben/anbinden noch der Reboot danach.
vor einer Stunde schrieb cj_berlin:Moin,
was ist denn mit der Public Folder *Mailbox*, wo der Ordner lebt? Vielleicht ist diese voll bzw. gegen Quota gelaufen?
Hm.... blöde Frage, aber wo prüfe ich das? In der ECP sehe ich unter -> Öffentliche Ordner -> "Postfächer für öffentliche Ordner" die entsprechende Mailbox.
Schaue ich mir die Postfachnutzung an, ist es schon merkwürdig. Hier steht, dass das Kontingent nicht eingeschränkt ist.
Klicke ich aber auf "Weitere Optionen..." steht doch eine Einschränkung drinnen, oder verstehe ich das falsch
Heißt also, wenn alle Public Folder in dieser Mailbox 11GB erreichen, ist Schluss oder?
Grüße
-
vor 9 Minuten schrieb Nobbyaushb:
Den Exchange mal rebootet?
Nein, noch nicht.
Das wäre mal die letzte Idee, richtig.
Werde ich machen und berichten.
vor 2 Minuten schrieb q617:Warum kein Exchange 2022?
Was genau hat das mit meinem Problem zu tun?
-
Hallo zusammen,
ich habe folgendes Problem Wir haben auf unserem Exchange 2016 noch ein paar Public Folders.
Bei einem habe ich nun das Problem, dass die User keine Mails mehr in diesen Public Folder verschieben können.
Sie erhalten die Fehlermeldung
ZitatDie Elemente können nicht verhoben werden. Der Nachrichtenspeicher hat die Maximalgröße erreicht. Reduzieren Sie die Datenmenge, in dem Sie Elemente markieren, die Sie nicht mehr benötigen und diese mit der Tastenkombination UMSCHALT*ENTF endgültig löschen.
Ich habe dann die Quota für den Public Folder angepasst (inkl. Unterordner)
Get-PublicFolder -Identity "<identity>" -Recurse | Set-PublicFolder -IssueWarningQuota 12GB -ProhibitPostQuota 12.5GB
Danach habe ich den Public Folder geprüft, es werden mir die neuen Werte auch angezeigt
ProhibitPostQuota : 12 GB IssueWarningQuota : 12.5 GB MaxItemSize : 100 MB
Mit folgenden Befehl habe ich dann die aktuelle Größe von dem Public Folder geprüft
Get-PublicFolder "<Identity>" -Recurse | Get-PublicFolderStatistics | Measure TotalItemSize -sum | Select @{N='Anzahl der Items'; E={$_.Count}}, @{N='Speiche r in Byte'; E={$_.Sum}} | fl
Als Größe wird mir dann angezeigt
ZitatAnzahl der Items : 595
Speicher in Byte : 9457889194Für mich heißt das, dass der Public Folder einen Grenzwert von 12,5GB hat und seine aktuelle Größe rund 9GB ist.
Warum erhalte ich dann aber in Outlook die Meldung, dass der Nachrichtenspeicher voll ist?
Hat hier jemand eine Idee? Cache Mode habe ich in Outlook schon deaktiviert um mögliches Caching auszuschließen.
Vielen Dank.
-
Ok, da sucht man längere Zeit nach einer Lösung und wenn man dann die Frage im Forum stellt, findet man die Lösung :)
Ich habe dann dem Computer Objekt in der AD einfach eine weitere Gruppe temporär als Mitgliedschaft hinzugefügt. Den Server neu gestartet und nun zeigt gpresult -r wieder alle Computermitgliedschaft an. Auch wenn man die temporäre Gruppe danach wieder entfernt.
Ich hoffe damit sind alle Probleme, die durch den Befehl winmgmt /resetrepository hervorgerufen wurden, nun beseitigt.
Besonders ärgerlich war, dass die GPOs plötzlich nicht mehr gewirkt haben.
Vielleicht hilft ja der Beitrag in Zukunft jemanden.
-
2
-
-
Hallo zusammen,
wir haben auf unseren Servern die Endpoint Protection von Kaspersky deinstalliert. Da nach der Deinstallation die neue Endpoint Protection die Meldung gebracht hat, dass noch eine andere Endpoint Protection installiert ist, haben wir uns an den Kaspersky Support gewendet.
Dieser hatte uns den Tipp gegeben, nach der Deinstallation den Befehl winmgmt /resetrepository auszuführen. Dies haben wir gemacht und danach ließ sich auch die neue Endpoint Protection sauber installiert.
Nun ist uns aber foglendes aufgefallen. Auf allen Server wo wir diesen Befehl ausgeführt haben, waren keine GPOs mehr aktiv.
Wir haben dies mit gpresult -r geprüft. Es waren keine zugewiesenen GPOs mehr aufgelistet und ebenso auch keine Sicherheitsgruppen mehr, die dem Computer zugeordnet sind.
Auch fehlt im der gpresult -r Ausagbe der Domänennamen und der Standort.
Die GPOs haben wir wieder aktiviert bekommen, nach dem wir ein gpupdate force ausgeführt haben (ein einfaches gpupdate hat nicht ausgereicht).
Die Gruppenmitgliedschaften werden aber weiterhin nicht angezeigt.
Auch ein Reboot des Servers hat nicht geholfen.
Hat jemand eine Idee wie man das wieder korrigieren kann? Wir sind wohl etwas blauäugig an den Befehl winmgmt /resetrepository rangegangen.
Es handelt sich bei den Servern um Server 2019. Domänenfunktionsebene und Gesamtstrukturfunktionsebene ist Windows Server 2016.
Hat jemand eine Idee wie ich das wieder korrigiert bekomme?
Vielen Dank für eure Hilfe.
Gruß
EDIT: Ich habe die Frage auch bei Administrator.de gestellt. Falls ich eine Lösung finde, werde ich diese in beiden Foren bekannt geben.
EDIT2: Es scheint aber so zu sein, dass die Gruppenzugehörigkeiten bei gpresult -r wohl nur nicht angezeigt werden. Hier wird ja z.b. auch normalerweise die Gruppe "Authentifzierte Benutzer" mit aufgeführt. Wir haben eine GPO die die lokalen Admins auf den Server regelt.
Ich habe nun eben mal einen Test durchgeführt und in die lokale "Administratoren" Gruppe auf dem betroffenen Server einen User aufgenommen. Dann habe ich gpupdate ausgeführt und der User wurde wieder aus der Gruppe entfernt. die GPO greift also und es wird auch erkannt, dass der Server noch in der Gruppe "Authentifizierte Benutzer" ist.
Somit ist das wohl nur ein Anzeigefehler, aber auch das ist unschön.
Wäre super wenn jemand eine Idee hätte wie man das wieder korrigiert bekommt. -
Am 14.7.2023 um 12:25 schrieb NorbertFe:
https://www.tech-faq.net/windows-server-2012-alias-erstellen/
Ich kann mir gar nicht vorstellen, dass du noch nie davon gehört hast. Zusätzlich noch den SPN hinterlegen, sonst gibts nur ekliges NTLM anstatt Kerberos. ;)
Ich hätte dazu noch mal eine Frage und hole den Beitrag noch mal hoch.
Ich habe jetzt mit netdom den Alias erstellt
netdom computername <computer> /add:<alias>
Danach habe ich mit
setspn -l <computername>
die SPNs geprüft und der neue Alias war schon als SPN eingetragen.
Damit muss ich doch gar nicht separat den SPN erstellten, es reicht doch der netdom Befehl, oder sehe ich das falsch?
Früher musste man ja noch die RegKeys eintragen, damit der Alias funktioniert. Da war dann wohl der manuelle setspn notwendig.
-
Hallo zusammen,
da wir gerade das NTLM Auditing aktiviert haben und prüfen wo bei uns überall NTLM noch verwendet wird, ist uns aufgefallen, dass 90% der NTLM Anfragen an unseren Print Server gehen.
Hier bin ich dann auf folgenden MS Artikel gestoßen
Es scheint massive Probleme geben zu können, wenn der damalige PrintNightmare Patch installiert wurde. Das führt unter anderem dazu, dass die Clients NTLM Anfragen an den Print Server schicken und das führt möglicherweise zu langsamen Druckaufträgen, DC Anmeldeproblemen usw. (sehr einfach zusammengefasst)
In dem Artikel ist ein sehr aufwendiger Prozess beschrieben um zu prüfen ob man betroffen ist.
In den Kommentaren ist eine einfachere Lösung zu finden.
Das Logging auf dem Client aktivieren
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\LSA\Kerberos\Parameters" -Name LogLevel -Type DWORD -Value 1 -Force
Dann ist im System EventLog die Security-Kerberos EventID 3 zu finden mit folgendem InhaltZitatA Kerberos error message was received:
on logon session
Client Time:
Server Time: 11:2:33.0000 3/14/2023 Z
Error Code: 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN
Extended Error:
Client Realm:
Client Name:
Server Realm: domain.com
Server Name: krbtgt/NT Authority
Target Name: krbtgt/NT email address removed for privacy reasonswenn ich nun vom Client drucke, sehe ich diese Einträge im EventLog.
Die Lösung ist, ein Reg Key zu setzen (bei uns ging es auch ohne den Print Spooler restart).
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\RPC" Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\RPC" -Name RpcNamedPipeAuthentication -Type DWORD -Value 2 -Force Restart-Service Spooler
Damit ist der Fehler im EventLog weg. Wir werden das nun auf allen Clients ausbringen und damit müsste ein großer Teil des NTLM Traffics entfallen und auch die möglichen Probleme beim drucken und der DC Anmeldung.
Viele haben wahrscheinlich schon NTLM deaktiviert und kennen möglicherweise die Lösung/Problem schon, aber vielleicht hilft es ja noch jemanden.
Quellen:
-
1
-
-
Danke Martin.
Dann werde ich mich mal an die Arbeit machen und die DNS Share Aliase überarbeiten.
-
vor 8 Stunden schrieb cj_berlin:
Ja, kann man. NTLM Audit Logging einschalten
Wäre das der richtige Weg oder gibt es andere Stellen wo man das Auditing aktivieren sollte?
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Network Security: Restrict NTLM: Audit NTLM authentication in this domain
Vielen Dank für deine Hilfe.
-
Danke euch.
Das der ping auch andere Technik nutzt, war mir im Detail nicht klar. Ich dachte der geht tatsächlich nur über den dns.
Wins und netbios ist bei uns deaktiviert.
Das interessante ist ja, wird der dns Eintrag von service Account über den dhcp vorgenommen (dns Einträge immer dynamisch aktualisieren), wird der bestehende dns Eintrag aktualisiert und der Client steht nur einmal im dns mit der jeweiligen IP (LAN oder WLAN).
Stellt man am dhcp es so ein (dns Eintrag nur noch Aufforderung von dhcp clients dynamisch aktualisieren) und der Client trägt sich selber ein, dann steht der Client zweimal im dns (einmal mit LAN und einmal mit der WLAN IP).
In diesem Fall gibt ein nslookup auch beide Einträge zurück und da frage ich mich eben, ob die korrekte Namensauflösung nur zu 50% funktioniert oder wie entschieden wird welcher dns Eintrag der aktuelle/ korrekte ist.
Wir haben genau deswegen ein Termin mit unserem Consultant. Dachte mir nur, vielleicht hat hier ja schon vorab eine Idee, weil das vielleicht ein bekannte Thema ist.
LG
-
Hallo zusammen,
Ich hoffe es ist ok, wenn ich mich hier mal einklinke.
Wir haben tatsächlich auch ein paar file shares auf die über einen dns alias zugegriffen wird.
Auch wir haben weder einen spn angepasst noch netdom bzw die regkeys eingetragen.
Es handelt sich hier um server 2019.
Fragen:
- Kann man prüfen warum bei uns die Zugriff trotzdem sauber funktionieren? Sehe ich ob es ein ntlm fallback gibt?
- registriert man den spn mit dem setspn?
- führt man den Befehl auf dem betroffenen Server oder dem dc aus?
Danke euch und mal wieder das Grundwissen aufgefrischt😇
-
Ja, da hat ms sich mal wieder was geleistet. In deren Screenshot war tatsächlich powerpoint.exe gestanden und das bsi hat das 1:1 so in deren Warnung übernommen.
Bis jetzt haben wir auch keine Probleme festgestellt und verteilen die regkeys jetzt an alle.
Soweit ich das richtig verstehe, verhindern die keys doch, das aus der engine vom ie11 subprozesse gestartet werden (z.b. dann word, excel, usw).
Es hieß ja, dass es Probleme mit office geben könnte. Das verstehe ich dann nicht, da die regkeys ja für den ie gelten.
Oder verdrehe ich da was?
-
vor 1 Stunde schrieb daabm:
Kann die Firewall das nicht
Du meinst, dass der dhcp der Firewall die dns Einträge im Windows dns vornimmt und man dort den Service Account hinterlegt?
Wir setzen fortigate ein und da ist mir aktuell nichts bekannt. Aber guter Hinweis, wir werden bei fortinet mal ein Ticket dazu eröffnen.
Kann jemand bestätigen, dass es normal ist das mehrere dns Einträge von demselben Client erstellt werden, wenn der Client selber die dns Einträge vornimmt?
Ich frage mich nur, wie dann die Namensauflösung funktioniert.
Das Verhalten ist aktuell wie folgt.
Client ist mit LAN und später mit WLAN verbunden. Im dns steht der Client dann zweimal drin, einmal mit der LAN IP und dann nochmal mit der wlan IP.
Nun ist der Client wieder mit LAN verbunden. Ich habe von 3 clients einen ping auf den Namen ausgeführt, wurden alle korrekt aufgelöst.
Gibt es eine Logik die prüft welcher von den beiden dns Einträgen aktuell/ erreichbar ist? Kann ich mir eigentlich nicht vorstellen. Aber war es dann nur Zufall, dass alle 3 Tests richtig aufgelöst haben?
Ich hätte erwartet, dass per Zufall zwischen den beiden dns Einträgen gewählt wird und man löst der dns auf die aktuelle IP auf und mal nicht.
-
Noch ein kleines Update
Werden die DNS Einträge vom Service Account, der im DHCP hinterlegt ist, eingetragen, werden die DNS Einträge aktualisiert.
So zum Beispiel wenn ein Notebook von LAN zu WLAN wechselt.
Werden die DNS Einträge direkt vom Computer Objekt geschrieben, wird der bestehende DNS Eintrag nicht aktualisiert, sondern man hat 2 Einträge im DNS.
Der DNS Eintrga von einem Notebook hat dann eben einmal die LAN und einmal die WLAN IP im DNS hinterlegt.
Ich würde jetzt vermuten, dass es dann ja Zufall ist ob bei der Namensauflösung die WLAN oder LAN IP genommen wird. Oder gibt es da eine Logik?
Das ist mir jetzt nur beim testen aufgefallen. Ändert aber nichts daran, dass ich für den VPN das Computer Objekt in der ACL benötige.
Hat da niemand eine Idee, wie man das automatisieren kann, dass automatisch noch das Computer Objekt in der ACL vom DNS Eintrag steht?
Ich wäre für Hilfe sehr dankbar :)
-
Hallo zusammen,
es gibt aktuell eine Zero Day Sicherheitslücke und für bestimmte Office Anwendungen noch kein Patch.
Es muss manuell ein RegKey eingetragen werden. "Nebenwirkungen" sind noch keine bekannt.
Wir testen gerade
Quelle:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36884 Visio.exe
-
2
-
-
Hallo zusammen,
wir haben folgende Konfig bei uns
- 2 DHCP Server im Failover Betrieb
- DNS Einstellung im DHCP Scope sieht wie folgt aus
- Service Account im DHCP hinterlegt für die DNS Registrierung
Bis vor kurzem hatten wir bei den DNS Einstellungen noch "DNS Einträge immer dynamisch aktualisieren" aktiviert und alle Einträge wurden durch den Service Account erstellt und dieser war auch in der ACL eingetragen.
Nun hatten wir folgendes Problem. Unsere VPN Clients erhalten die IP nicht vom internen DHCP, sondern von der Firewall.
Damit haben diese Clients sich immer versucht selber in den DNS Einzutragen und konnten den bestehenden Eintrag nicht ändern, da dort ja der Service Account hinterlegt war. Hat man den DNS Eintrag gelöscht, konnte der Client sich aus dem VPN im DNS eintragen, aber wenn der Client dann wieder im internen LAN war hatten wir wieder das Problem, da dann das Computer Objekt in der ACL vom DNS Eintrag stand und der Service Account diesen nicht ändern konnte.
Deshalb haben wir die Einstellung auf oben geändert, damit die Windows Clients immer ihre DNS Einträge selber vornehmen und damit die Änderung vom VPN und LAN funktioniert.
So richtig sauber läuft das aber nicht, da doch immer mal wieder ein Client vom DHCP Service Account eingetragen wird.
Ich habe dann diesen MS Beitrag dazu gefunden.
Hier geht es genau um unsere Problematik
ZitatHow to segregate between Case 1 and Case 2 ?
Let's assume there are 5000 existing dynamic records, some of which are updated by the system itself (Case 1) and some of which are updated by the DHCP server (Case 2).
How to segregate this?
One way is to use the first script and get the owner of the record. If the owner is the system itself, the record is registered and will be updated by the system. If the owner is DHCP server, the record is registered and will be updated by DHCP server.
However, if there is confusion, and to avoid any possible outage after securing the zone, the best approach is to configure both permissions.
So in this approach, each dynamic record will have two entries added with full control permission:
- The system computer account.
- The DHCP user (service) account: “DHCP_Update” in this case.
This is the safest approach, as it will ensure that after securing the zone the record would be updated, no matter who requests the update, system itself or DHCP server. So in this way, we can avoid/minimize any possible outage after changing an existing DNS Zone from non-secure to secure.
If we have to change the security settings for multiple DNS zones which are already in production, the best approach is to change it in one zone, observe the result for few weeks and then proceed for others one by one. In case of any critical issue, the backout plan is to change back the settings from “Secure Only” to “Nonsecure and secure”.
However, the best approach is to secure the zone before going to production, to avoid all these future complexities
Genau diese Idee hatte ich auch, es müsste einfach für jeden DNS Eintrag automatisch das Computer Objekt zusätzlich in die ACL eingetragen werden. Dann hätte ich den Service Account und das Computer Objekt in der ACL und der DNS Eintrag könnte aus dem VPN und aus dem LAN vom Client geändert werden.
Es wird dort auch ein Script erwähnt, aber das ist leider nicht mehr verfügbar.
Hat von euch jemand eine Idee wie ich das realisieren könnte?
Ein Script wäre zwar ganz nett oder setzt man da die Berechtigung direkt im Schema/DNS, damit neu erstelle Einträge gleich das Computer Objekt in die ACL eingetragen bekommen?
Vielen Dank und Grüße
-
Vielen Dank.
Die Info habe ich tatsächlich immer gründlich ignoriert
Danke für eure Hilfe.
-
vor 5 Stunden schrieb cj_berlin:
Das ist aber eine etwas andere Aussage
- Du schreibst: Ich habe nun gelesen, dass man die Advance Audit Policy nur in der Default Domain Policy aktivieren soll,
- Im Thread steht: Damit Adavnced Audit Policies in jeder GPO funktionieren, muss in der DDP die audit.csv physisch präsent sein (ggfls. mit minimalem Inhalt)
Hi Evgenij,
ich hatte mich auf die grün markierte Antwort in dem Thread bezogen
ZitatI got the answer to the problem. Advance Audit policies are only working from Default Domain Policy. If I do the settings on a separate GPO, it is not applying even if I enforce the GPO. Both GPOs are applied on the top domain level, the custom GPO works for other settings but fails for Advance auditing. When the settings are shifted to Default Domain Policy, auditing starts working.
This looks like bug which Microsoft may want to look at or is their any specific reason why this happens.
Du hast Recht, dass auch das im nächsten Beitrag erwähnt wird. Ich hatte bei uns geprüft ob die audit.csv in der DDP vorhanden ist. Das war sie nicht und ich habe habe sie erstellten lassen, in dem ich eben eine Änderung gemacht habe und diese dann wieder auf default zurückgesetzt habe. Nun gibt es die audit.csv.
Sorry - diese Info hatte ich komplett vergessen.
Es ist nun aktuell so
- In einer dedizierten GPO wird das advanced Audit Policies gesetzt.
- Auf dem entsprechenden Server sehe ich die GPO Einstellungen im gpedit.msc und im rsop.msc nicht
- Im gpresult -h "html file" und mit auditpol /get /category:* sehe ich die Einstellungen
Es wird ja auch das Security EventLog gefüllt, ich hätte einfach erwartet das ich diese Einstellung im gpedit.msc sehe, oder zumindest im rsop.msc.
Aber anscheinend macht MS da was es will. Einige GPO Einstellungen werden in der gpedit.msc angezeigt (z.B. in den Sicherheitsoptionen mit dem geänderten Icon) und andere nicht.
VG
-
Hallo zusammen,
danke euch.
Ich hatte das nicht in einem offiziellen MS Dokument gelesen, diese Behauptung hatte jemand im MS Forum aufgestellt
Mir ist klar, dass ich mit gpedit.msc die lokalen Richtlinien sehe und diese von den Domain Policies überschrieben werden.
Ich dachte nur, dass ich die Advanced Audit Policy "Überschreibungen" in der gpedit.msc sehe (wie z.B. in den Sicherheitsoptionen ja zu sehen ist, das Icon ändert sich).
Ich hätte aber zumindest erwartet, dass es im rsop.msc zu sehen ist. Aber auch dort sehe ich die Änderungen nicht.
Laut dem oben verlinkten Artikel verstehe ich das auch so, oder stehe ich komplett auf dem Schlauch?
Gruß
WSUS GPO RegKeys fehlen plötzlich bei einigen Clients
in Windows 10 Forum
Geschrieben
Das war vor meiner Zeit
Aber als Client Management System funktioniert ZCM recht gut. Mal abgesehen von dem WSUS Problem, wenn das jetzt davon kommen sollte.
Aber wir setzen es schon seit gut 10 Jahren ein und bisher hat das immer sehr gut funktioniert.
Mal schauen was jetzt dabei rauskommt.
Schönes Wochenende zusammen.