20
Active Directory - Mitglieder zu Gruppe hinzufügen Rechte
Moin zusammen,
ich nutze einen Samba4 Server auf meinem Testserver, den ich als Active Directory Domain Controller aufgesetzt habe. Es läuft auch alles super, wie es zu erwarten ist.
Ich habe einzig allein ein Problem mit den Rechten, wenn ich einen Benutzer zu einer Gruppe hinzufügen möchte.
Ich habe zwei Gruppen: Mitarbeiter und Gast.
Sowie einen Benutzer "test.mitarbeiter". Der "test.mitarbeiter" befindet sich in der Gruppe Mitarbeiter.
Alle Mitarbeiter die in der Gruppe Mitarbeiter sind, soll es möglich sein Benutzer zur Gruppe Gast hinzufügen. Ich habe also die Sicherheitseinstellungen der Gruppe "Gast" aufgerufen und unter Erweitert -> Hinzufügen den Principal "Mitarbeiter" mit der Option "Nur auf dieses Objekt anwenden" das Recht "Mitglied schreiben hinzugefügt". (Das ist auch das einzige, dass ADUC mit dem Delegation Wizard setzt, wenn man "Darf Mitglieder zur Gruppe hinzufügen auswählt".
Ich teste meine LDAP immer mit LDAPAdmin ((http://www.ldapadmin.org) hat auch andere Gründe) und wollte hier einen Benutzer zu dieser Gruppe hinzufügen. Allerdings kam lediglich die Fehlermeldung, dass die Rechte nicht ausreichend seien.
Nach intensiveren Bruteforcen welcher Parameter denn der richtige ist, damit es mit LDAPAdmin klappt, fand ich heraus, dass es funktioniert, wenn man das Schreiben von "groupType" erlaubt.
Jetzt sehe ich allerdings keinen direkten Zusammenhang zwischen GroupType und den Mitgliedern einer Gruppe.
Hat vielleicht einer von euch eine Idee, wieso das so ist? Ist das ein Bug in LDAPAdmin oder liegt es an einem Missverständnis der "Mitglieder hinzufügen"-Rechte?
Disclaimer:
Ich poste diesen Thread unter Windows Server, da ich eher von einer Fehlbedienung ausgehe und da RSAT identisch mit den Windows Server Tools ist, erhoffe ich mir hier mehr Resonanz ;).
ich nutze einen Samba4 Server auf meinem Testserver, den ich als Active Directory Domain Controller aufgesetzt habe. Es läuft auch alles super, wie es zu erwarten ist.
Ich habe einzig allein ein Problem mit den Rechten, wenn ich einen Benutzer zu einer Gruppe hinzufügen möchte.
Ich habe zwei Gruppen: Mitarbeiter und Gast.
Sowie einen Benutzer "test.mitarbeiter". Der "test.mitarbeiter" befindet sich in der Gruppe Mitarbeiter.
Alle Mitarbeiter die in der Gruppe Mitarbeiter sind, soll es möglich sein Benutzer zur Gruppe Gast hinzufügen. Ich habe also die Sicherheitseinstellungen der Gruppe "Gast" aufgerufen und unter Erweitert -> Hinzufügen den Principal "Mitarbeiter" mit der Option "Nur auf dieses Objekt anwenden" das Recht "Mitglied schreiben hinzugefügt". (Das ist auch das einzige, dass ADUC mit dem Delegation Wizard setzt, wenn man "Darf Mitglieder zur Gruppe hinzufügen auswählt".
Ich teste meine LDAP immer mit LDAPAdmin ((http://www.ldapadmin.org) hat auch andere Gründe) und wollte hier einen Benutzer zu dieser Gruppe hinzufügen. Allerdings kam lediglich die Fehlermeldung, dass die Rechte nicht ausreichend seien.
Nach intensiveren Bruteforcen welcher Parameter denn der richtige ist, damit es mit LDAPAdmin klappt, fand ich heraus, dass es funktioniert, wenn man das Schreiben von "groupType" erlaubt.
Jetzt sehe ich allerdings keinen direkten Zusammenhang zwischen GroupType und den Mitgliedern einer Gruppe.
Hat vielleicht einer von euch eine Idee, wieso das so ist? Ist das ein Bug in LDAPAdmin oder liegt es an einem Missverständnis der "Mitglieder hinzufügen"-Rechte?
Disclaimer:
Ich poste diesen Thread unter Windows Server, da ich eher von einer Fehlbedienung ausgehe und da RSAT identisch mit den Windows Server Tools ist, erhoffe ich mir hier mehr Resonanz ;).
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 362644
Url: https://administrator.de/contentid/362644
Ausgedruckt am: 17.11.2024 um 01:11 Uhr
20 Kommentare
Neuester Kommentar
Hi,
Teste mal, ob es ausreicht, wenn Du der Gruppe "Mitglieder" explizit Lese-Recht für groupType erteilst.
Der Zusammenhang ist hier, dass man je nach Gruppentyp andere Mitglieder hinzufügen kann. Zu einer Globalen Gruppe z.B. keine Benutzer und Gruppen anderer Domänen, usw. Ich vermute, dass LDAPAdmin eigentlich einfach nur den Gruppentyp auslesen will. Oder es bietet bei Bedarf die Möglichkeit an, den Gruppentyp zu ändern. z.B. wenn eben doch versucht einen Benutzer einer anderen Domäne hinzufügen will, dass es dann anbietet, den Gruppentyp in "domänenlokal" oder "universell" zu ändern. Ist nur ne Vermutung von mir.
In jedem Fall würde ich niemals einem Nicht-Admin das Recht einräumen, einen Gruppentyp zu ändern! Sowas kann fatale Folgen haben.
E.
Jetzt sehe ich allerdings keinen direkten Zusammenhang zwischen GroupType und den Mitgliedern einer Gruppe.
Na doch, diesen gibt es schon. Aber man muss diesen nicht schreiben können, um die Mitglieder zu schreiben.Teste mal, ob es ausreicht, wenn Du der Gruppe "Mitglieder" explizit Lese-Recht für groupType erteilst.
Der Zusammenhang ist hier, dass man je nach Gruppentyp andere Mitglieder hinzufügen kann. Zu einer Globalen Gruppe z.B. keine Benutzer und Gruppen anderer Domänen, usw. Ich vermute, dass LDAPAdmin eigentlich einfach nur den Gruppentyp auslesen will. Oder es bietet bei Bedarf die Möglichkeit an, den Gruppentyp zu ändern. z.B. wenn eben doch versucht einen Benutzer einer anderen Domäne hinzufügen will, dass es dann anbietet, den Gruppentyp in "domänenlokal" oder "universell" zu ändern. Ist nur ne Vermutung von mir.
In jedem Fall würde ich niemals einem Nicht-Admin das Recht einräumen, einen Gruppentyp zu ändern! Sowas kann fatale Folgen haben.
E.
1
Vielen Dank für die Antwort.
Tatsächlich versucht LDAPAdmin das groupType Objekt zu schreiben. Vermutlich ist der Wizard, um Benutzer zu einer Gruppe hinzuzufügen in LDAPAdmin so konzipiert, dass es eben die Möglichkeit gibt automatisch den Gruppentyp zu ändern, sofern es erforderlich ist.
Wenn ich in LDAPAdmin lediglich das Member Attribut manuell hinzufüge, funktioniert alles einwandfrei, ohne die Schreibrechte auf groupType.
Auch das ADUC hat keine Probleme damit die User hinzuzufügen, wenn keine Schreibrechte auf groupType vorhanden sind.
Ein weiteres Thema, was indirekt hiermit zu tun hat:
Ich habe einen Fileshare, auf dem ich per ACLs einer Gruppe Schreibrechte gegeben habe. Wenn ich dieser Gruppe jetzt einen Benutzer hinzufüge, der bereits angemeldet ist, dann bekommt dieser keine Schreibrechte auf den Share. Soweit ich weiß liegt dies einfach an Kerberos dessen Ticket das ja die Gruppen beinhaltet, die neue Gruppenzugehörigkeit noch nicht enthält und erst bei einem erneuten Login aktualisiert wird.
Folglich müsste ich den Benutzer, den ich zu einer Gruppe hinzufüge während er Arbeitet darum bitten, sich einmal neu anzumelden. Dies hat natürlich den großen Nachteil, dass alle Programme geschlossen werden. Des Weiteren gibt es ja auch die Möglichkeit den Prozess "explorer.exe" mit Hilfe von "RunAs" erneut auszuführen, wodurch die Gruppen auch geupdatet werden. Hier gibt es aber wohl den Nachteil, dass z.B. Word und Excel davon nichts mitbekommen und auch hier ein manueller Neustart nötig ist.
Wie würdet ihr an dieses Problem rangehen?
Tatsächlich versucht LDAPAdmin das groupType Objekt zu schreiben. Vermutlich ist der Wizard, um Benutzer zu einer Gruppe hinzuzufügen in LDAPAdmin so konzipiert, dass es eben die Möglichkeit gibt automatisch den Gruppentyp zu ändern, sofern es erforderlich ist.
Wenn ich in LDAPAdmin lediglich das Member Attribut manuell hinzufüge, funktioniert alles einwandfrei, ohne die Schreibrechte auf groupType.
Auch das ADUC hat keine Probleme damit die User hinzuzufügen, wenn keine Schreibrechte auf groupType vorhanden sind.
Ein weiteres Thema, was indirekt hiermit zu tun hat:
Ich habe einen Fileshare, auf dem ich per ACLs einer Gruppe Schreibrechte gegeben habe. Wenn ich dieser Gruppe jetzt einen Benutzer hinzufüge, der bereits angemeldet ist, dann bekommt dieser keine Schreibrechte auf den Share. Soweit ich weiß liegt dies einfach an Kerberos dessen Ticket das ja die Gruppen beinhaltet, die neue Gruppenzugehörigkeit noch nicht enthält und erst bei einem erneuten Login aktualisiert wird.
Folglich müsste ich den Benutzer, den ich zu einer Gruppe hinzufüge während er Arbeitet darum bitten, sich einmal neu anzumelden. Dies hat natürlich den großen Nachteil, dass alle Programme geschlossen werden. Des Weiteren gibt es ja auch die Möglichkeit den Prozess "explorer.exe" mit Hilfe von "RunAs" erneut auszuführen, wodurch die Gruppen auch geupdatet werden. Hier gibt es aber wohl den Nachteil, dass z.B. Word und Excel davon nichts mitbekommen und auch hier ein manueller Neustart nötig ist.
Wie würdet ihr an dieses Problem rangehen?
Wie @135333 schon schreibt. Du könntest diesen Befehl als Verknüpfung auf den Desktop oder ins Startmenü legen.
Ja das habe ich bereits probiert. Nach einem klist purge werden alle Kerberos Tickets gelöscht.
Verbinde ich mich jetzt neu mit dem Share wurden die Gruppen allerdings nicht geupdatet. Auch in klist tauchen keine neuen Tickets auf.
Edit:// Oder muss ich dann auch die Prozesse neustarten? Dann habe ich ja das gleiche Problem nur in grün, wie oben beschrieben
Verbinde ich mich jetzt neu mit dem Share wurden die Gruppen allerdings nicht geupdatet. Auch in klist tauchen keine neuen Tickets auf.
Edit:// Oder muss ich dann auch die Prozesse neustarten? Dann habe ich ja das gleiche Problem nur in grün, wie oben beschrieben
Timeout abwarten oder setzen!
Temporäre Credentials während einer Windows-Sitzung wieder löschen
Temporäre Credentials während einer Windows-Sitzung wieder löschen
1
Oh, vielen Dank! Das wusste ich noch nicht. Werde ich direkt ausprobieren.
Verbinde ich mich jetzt neu mit dem Share wurden die Gruppen allerdings nicht geupdatet. Auch in klist tauchen keine neuen Tickets auf.
Ja, sorry, mein Fehler.Das musst Du nicht am Client sondern am Server ausführen!
Purge the Kerberos client ticket cache for all sessions (Powershell one-liner)
Beim Zugriff auf ein Share kommt es doch auf das Ticket der Sitzung auf dem Fileserver an. Hatte ich nicht bedacht.
Das einfache "klist purge" in der Clientsitzung ist nur bei lokalen Ressourcen relevant.
Also Benutzer ändern (dessen Gruppenmitgliedschaft) und dann als Admin auf dem Server entweder die Sitzung des Benutzers trennen (kann man i.A. problemlos tun) oder z.B. mit o.g. PS-Script die Tickets der Sitzungen löschen.
1
Vielen Dank für die Antwort.
Da ich Samba4 als Domänen Controller nutze, kann ich hier auf dem FileServer Domain Member folgendes ausführen:
Dann läuft es sofort wie erwünscht. Das einzige Problem ist wohl, was passiert, wenn ein User währenddessen eine große Datei auf den Share überträgt? Schlägt die Übertragung dann einfach Fehl?
Da ich Samba4 als Domänen Controller nutze, kann ich hier auf dem FileServer Domain Member folgendes ausführen:
smbcontrol smbd kill-client-ip <IP>Dann läuft es sofort wie erwünscht. Das einzige Problem ist wohl, was passiert, wenn ein User währenddessen eine große Datei auf den Share überträgt? Schlägt die Übertragung dann einfach Fehl?
Ich habe noch ein weiteres kleines Problem:
Ich nutze Windows 10 1709 mit Profile Roaming was ja scheinbar öfter mal Probleme macht.
Jetzt habe ich das Phänomen, dass der Logout teilweise extrem lange dauert (ca. 1-2 Minuten).
Ich habe mich ca. 20 An und Abgemeldet, wodurch ich zu folgendem Ergebnis kam:
- Wenn sich ein User anmeldet und direkt wieder abmeldet, so dauert der Logout extrem lange.
- Wenn sich der User anmeldet und erst ca. 2-3 Minuten wartet und sich dann abmeldet, dann geht der Logout innerhalb von ein paar Sekunden.
(Es gab teilweise auch Ausnahmen, da ging der Logout sofort, auch wenn man nicht 2-3 Minuten gewartet hat, aber dann kam, wie gesagt, das Ereignis auch nicht).
Ich habe auf den FileShare ein Dateizugriffmonitor angelegt und gesehen, dass Windows nach ca. 5s, bei dem extrem langsamen Logout keinen Zugriff mehr auf die Dateien im Share vornimmt. Folglich wurden alle Änderungen des Roaming Profiles übertragen. Dennoch dauert der Logout lange.
Was mir auch aufgefallen ist, ist dass Windows bereits im Eventviewer ankündigt, dass der Logout jetzt lange dauern kann (6005).
Nachdem ich ein paar Minuten vor dem Logout gewartet habe, kommt diese Meldung nicht.
Woran könnte dies also liegen? Rödelt Windows im Hintergrund noch etwas rum, was den Logoutprozess verzögert?
Edit:// Ich lösche die Benutzerprofile, sobald sich der User abmeldet. Könnte es sein, dass Windows da irgendetwas in AppData/Local generiert?
Ich nutze Windows 10 1709 mit Profile Roaming was ja scheinbar öfter mal Probleme macht.
Jetzt habe ich das Phänomen, dass der Logout teilweise extrem lange dauert (ca. 1-2 Minuten).
Ich habe mich ca. 20 An und Abgemeldet, wodurch ich zu folgendem Ergebnis kam:
- Wenn sich ein User anmeldet und direkt wieder abmeldet, so dauert der Logout extrem lange.
- Wenn sich der User anmeldet und erst ca. 2-3 Minuten wartet und sich dann abmeldet, dann geht der Logout innerhalb von ein paar Sekunden.
(Es gab teilweise auch Ausnahmen, da ging der Logout sofort, auch wenn man nicht 2-3 Minuten gewartet hat, aber dann kam, wie gesagt, das Ereignis auch nicht).
Ich habe auf den FileShare ein Dateizugriffmonitor angelegt und gesehen, dass Windows nach ca. 5s, bei dem extrem langsamen Logout keinen Zugriff mehr auf die Dateien im Share vornimmt. Folglich wurden alle Änderungen des Roaming Profiles übertragen. Dennoch dauert der Logout lange.
Was mir auch aufgefallen ist, ist dass Windows bereits im Eventviewer ankündigt, dass der Logout jetzt lange dauern kann (6005).
Nachdem ich ein paar Minuten vor dem Logout gewartet habe, kommt diese Meldung nicht.
Woran könnte dies also liegen? Rödelt Windows im Hintergrund noch etwas rum, was den Logoutprozess verzögert?
Edit:// Ich lösche die Benutzerprofile, sobald sich der User abmeldet. Könnte es sein, dass Windows da irgendetwas in AppData/Local generiert?
wenn ein User währenddessen eine große Datei auf den Share überträgt? Schlägt die Übertragung dann einfach Fehl?
Nein, sollte nicht. Denn zu diesem Zeitpunkt sind die Zugriffsberechtigungen für diese Aktion bereits ausgehandelt.Ich nutze Windows 10 1709 mit Profile Roaming was ja scheinbar öfter mal Probleme macht.
Im Zusammenspiel mit einem Windows Fileserver haben wir da Null Probleme.Jetzt habe ich das Phänomen, dass der Logout teilweise extrem lange dauert (ca. 1-2 Minuten).
Ich habe mich ca. 20 An und Abgemeldet, wodurch ich zu folgendem Ergebnis kam:
- Wenn sich ein User anmeldet und direkt wieder abmeldet, so dauert der Logout extrem lange.
- Wenn sich der User anmeldet und erst ca. 2-3 Minuten wartet und sich dann abmeldet, dann geht der Logout innerhalb von ein paar Sekunden.
Teste das mal mit einem Windows Server. Das kann zum Test auch eine Workstation sein. (keine Windows Server Edition)Ich habe mich ca. 20 An und Abgemeldet, wodurch ich zu folgendem Ergebnis kam:
- Wenn sich ein User anmeldet und direkt wieder abmeldet, so dauert der Logout extrem lange.
- Wenn sich der User anmeldet und erst ca. 2-3 Minuten wartet und sich dann abmeldet, dann geht der Logout innerhalb von ein paar Sekunden.
Edit:// Ich lösche die Benutzerprofile, sobald sich der User abmeldet. Könnte es sein, dass Windows da irgendetwas in AppData/Local generiert?
Ja, natürlich sorgt das dafür, dass die Anmeldezeiten dadurch länger werden, weil er jedes Mal alles neu kopieren muss.Warum löschst Du es?
Beim Abmelden sollte es so sein, dass das Löschen erst nach dem Abmelden der Sitzung erfolgt. D.h. aber, dass alle Prozesse dieses Benutzers beendet sein müssen und nicht bloß die sichtbaren.
Edit:
Allgemein: siehe auch "Ordnerumleitung"'
Moin,
vielleicht hast du ja einmal kurz die Möglichkeit dich an einem Roaming Profil anzumelden und direkt wieder abzumelden mit der aktuellen Windows 10 Version? Du setzt ja scheinbar ein Windows Server ein. Bevor ich einen Windows Server aufsetzen muss etc. Das wäre echt nett .
Beim Anmelden habe ich keine Probleme. Nur beim direkten wieder Abmelden nach dem Login. Vermutlich wartet Windows dann auf irgendeinen Prozess, bis der beendet ist.
Ich lösche den Benutzerordner, weil auf dem Computer diverse Nutzer arbeiten sollen. Ich hätte sonst ca 100 lokale Benutzerprofile die entsprechend Platz benötigen.
vielleicht hast du ja einmal kurz die Möglichkeit dich an einem Roaming Profil anzumelden und direkt wieder abzumelden mit der aktuellen Windows 10 Version? Du setzt ja scheinbar ein Windows Server ein
. Bevor ich einen Windows Server aufsetzen muss etc. Das wäre echt nett .Beim Anmelden habe ich keine Probleme. Nur beim direkten wieder Abmelden nach dem Login. Vermutlich wartet Windows dann auf irgendeinen Prozess, bis der beendet ist.
Ich lösche den Benutzerordner, weil auf dem Computer diverse Nutzer arbeiten sollen. Ich hätte sonst ca 100 lokale Benutzerprofile die entsprechend Platz benötigen.
vielleicht hast du ja einmal kurz die Möglichkeit dich an einem Roaming Profil anzumelden und direkt wieder abzumelden mit der aktuellen Windows 10 Version?
Keine Probleme in aktuellster Lab-Config. Geht ruck zuck auch mit Löschen der Profile. Mach halt mal ein Logging mit ProcMon.Ich schätze mal da blockiert dein AV oder anderer Dienst die Abmeldung.
vielleicht hast du ja einmal kurz die Möglichkeit dich an einem Roaming Profil anzumelden und direkt wieder abzumelden mit der aktuellen Windows 10 Version?
Ich und die anderen auch, arbeiten am Win10 Pro 1709. Sonst würde ich nicht schreiben "haben wir da Null Probleme."Beim Anmelden habe ich keine Probleme. Nur beim direkten wieder Abmelden nach dem Login. Vermutlich wartet Windows dann auf irgendeinen Prozess, bis der beendet ist.
Ich erinnere mich, hier im Forum vor kurzen schon mal sowas im Zusammenhang mit eiem NAS als Filserver gelesen zu haben. Suche Du einfach mal ...Ich lösche den Benutzerordner, weil auf dem Computer diverse Nutzer arbeiten sollen. Ich hätte sonst ca 100 lokale Benutzerprofile die entsprechend Platz benötigen.
Du hast einen PC, an welchem 100 verschiedene Benutzer abwechselnd arbeiten?Wenn Dein geschildertes Problem nur dann auftritt, wenn man sich sofort nach Anmeldung wieder abmeldet: Wie oft kann/wird dann sowas im Produktivfall voraussichtlich eintreten?
Moin,
ich konnte das Problem auf zwei VMs jetzt zuverlässig reproduzieren. Sobald ich die GPO setze, dass die Roaming Profiles beim Ausloggen gelöscht werden sollen, dauert der Logout ewig. Lösche ich die GPO funktioniert alles wunderbar, sehr schnell und über mehrere VMs hinweg wird das Profil geshared.
Die spannende Frage ist jetzt, wieso funktioniert es nicht (bzw. dauert lange), wenn man das Löschen des Profils aktiviert hat? Die einzig sinnvolle Erklärung die ich habe, ist, dass Windows intern versucht das Profil zu löschen. Allerdings lockt irgendein Prozess das Löschen bestimmter Dateien (vermutlich in AppData/Local, wo die ganzen Dateien für die ganzen Apps liegen). Windows wartet also bis er die Dateien löschen kann und meldet dann den User ab. Wenn der Ordner nicht gelöscht wird, so kann Windows im Hintergrund an den Dateien weiter werkeln (woran auch immer) und der Benutzer wird abgemeldet.
Interessant, finde ich aber, dass es bei euch ja scheinbar auf einem Windows Server MIT Profil löschen einwandfrei funktioniert?
Ich sehe da jetzt eigentlich keinen Zusammenhang ob es ein Windows oder Samba Server ist.
Vielleicht habt ihr ja noch andere Ideen? Ich ermittel mal mit ProcMon welche Dateien wann gelöscht werden.
Edit:// Man sieht in ProcMon, das da plötzlich eine Lücke von mehr als 1 Minute ist, bevor der das Profil weiter löscht.
Habt ihr Ideen wie ich das genauer analysieren/filtern kann? Wollte keine 2 Millionen Einträge händisch durchsuchen :D
ich konnte das Problem auf zwei VMs jetzt zuverlässig reproduzieren. Sobald ich die GPO setze, dass die Roaming Profiles beim Ausloggen gelöscht werden sollen, dauert der Logout ewig. Lösche ich die GPO funktioniert alles wunderbar, sehr schnell und über mehrere VMs hinweg wird das Profil geshared.
Die spannende Frage ist jetzt, wieso funktioniert es nicht (bzw. dauert lange), wenn man das Löschen des Profils aktiviert hat? Die einzig sinnvolle Erklärung die ich habe, ist, dass Windows intern versucht das Profil zu löschen. Allerdings lockt irgendein Prozess das Löschen bestimmter Dateien (vermutlich in AppData/Local, wo die ganzen Dateien für die ganzen Apps liegen). Windows wartet also bis er die Dateien löschen kann und meldet dann den User ab. Wenn der Ordner nicht gelöscht wird, so kann Windows im Hintergrund an den Dateien weiter werkeln (woran auch immer) und der Benutzer wird abgemeldet.
Interessant, finde ich aber, dass es bei euch ja scheinbar auf einem Windows Server MIT Profil löschen einwandfrei funktioniert?
Ich sehe da jetzt eigentlich keinen Zusammenhang ob es ein Windows oder Samba Server ist.
Vielleicht habt ihr ja noch andere Ideen? Ich ermittel mal mit ProcMon welche Dateien wann gelöscht werden.
Edit:// Man sieht in ProcMon, das da plötzlich eine Lücke von mehr als 1 Minute ist, bevor der das Profil weiter löscht.
Habt ihr Ideen wie ich das genauer analysieren/filtern kann? Wollte keine 2 Millionen Einträge händisch durchsuchen :D
In ProcMon gibt es eine TimeLineansicht "ProcessTree"' in der du siehst welcher Prozess die Wartezeit verursacht.
http://www.winhelponline.com/blog/procmon-track-process-creation-exit-t ...
http://www.winhelponline.com/blog/procmon-track-process-creation-exit-t ...
1
Vielen Dank, das hat mich auf die richtige Spur gebracht.
Man sieht im Process Tree, dass während des Abmelden noch der Windows Search Dienst läuft. Das ist wohl der Dienst, der das Dateisystem analysiert und indextiert, sodass die Suche funktioniert. Vermutlich merkt Windows, dass dieser Dienst läuft und schreibt folglich in den Eventlog, dass das Abmelden etwas dauern kann.
Wenn ein Nutzer nun länger an einem PC arbeitet (was in der Regel ja der Fall ist), so ist der Search Indexer fertig und der Logout geht schnell.
Sobald ich diesen Dienst deaktiviere läuft der Logout sehr schnell.
Jetzt ist die Frage wie man das Problem beheben kann. Den SearchIndexer zu deaktivieren wäre eine Lösung. Bei einer HDD wäre die Platte dann ja bei jedem neuem Login am rödeln, was auf Dauer auch nicht optimal ist.
Eine andere Lösung wäre wohl ein Logout-Skript, dass beim Abmelden den Dienst manuell killt, sodass Windows nicht wartet bis er von selber gestoppt wurde.
P.S. Könnt ihr bei euch im Lab ggf. mal prüfen, ob der SearchIndexer Dienst läuft, nachdem ihr euch angemeldet habt? Im TaskManager sollte hier die SearchIndexer.exe auftauchen. Falls nicht ggf. den Dienst einmal starten und schauen, ob ihr den Fehler reproduzieren könnt.
Man sieht im Process Tree, dass während des Abmelden noch der Windows Search Dienst läuft. Das ist wohl der Dienst, der das Dateisystem analysiert und indextiert, sodass die Suche funktioniert. Vermutlich merkt Windows, dass dieser Dienst läuft und schreibt folglich in den Eventlog, dass das Abmelden etwas dauern kann.
Wenn ein Nutzer nun länger an einem PC arbeitet (was in der Regel ja der Fall ist), so ist der Search Indexer fertig und der Logout geht schnell.
Sobald ich diesen Dienst deaktiviere läuft der Logout sehr schnell.
Jetzt ist die Frage wie man das Problem beheben kann. Den SearchIndexer zu deaktivieren wäre eine Lösung. Bei einer HDD wäre die Platte dann ja bei jedem neuem Login am rödeln, was auf Dauer auch nicht optimal ist.
Eine andere Lösung wäre wohl ein Logout-Skript, dass beim Abmelden den Dienst manuell killt, sodass Windows nicht wartet bis er von selber gestoppt wurde.
P.S. Könnt ihr bei euch im Lab ggf. mal prüfen, ob der SearchIndexer Dienst läuft, nachdem ihr euch angemeldet habt? Im TaskManager sollte hier die SearchIndexer.exe auftauchen. Falls nicht ggf. den Dienst einmal starten und schauen, ob ihr den Fehler reproduzieren könnt.
Ich wiederhole nochmal meine Frage:
Wenn ich richtig gelesen habe, tritt das bei Euch nur auf, wenn das Abmelden unmittelbar nach dem Anmelden erfolgt. Habe ich das richtig verstanden?
Falls ja:
Wie oft ist zu erwarten, dass dieser Fall denn eintreten wird? Falls Du die Wahrscheinlichkeit als gering einstufen kannst (ich tippe auf "sehr gering"), dann kann es Dir doch egal sein, oder?
Wenn ich richtig gelesen habe, tritt das bei Euch nur auf, wenn das Abmelden unmittelbar nach dem Anmelden erfolgt. Habe ich das richtig verstanden?
Falls ja:
Wie oft ist zu erwarten, dass dieser Fall denn eintreten wird? Falls Du die Wahrscheinlichkeit als gering einstufen kannst (ich tippe auf "sehr gering"), dann kann es Dir doch egal sein, oder?
Ja, es kann mir prinzipiell egal sein, dennoch interessierten mich die Zusammenhänge, wieso so ein Fehler Auftritt. Wenn jemand fragen sollte, warum die Abmeldung so lange dauert kann man einen Grund nennen
