15
Registry-GPO wird erst beim zweiten Login übernommen
Wenn ich eine GPO anlege, in der ein Registrywert direkt angegeben wird (Einstellungen\Windows Einstellungen\Registry), wird dieser erst nach dem 2. Login übernommen. Wenn ich nach dem ersten Login mit rsop.msc schaue, steht die Richtlinie dort als erfolgreich verarbeitet drin. Aber erst nach nochmaligem Logout und Login sind die Registryeinstellungen da.
Es handelt sich um Einstellungen im Zweig HKLM\System. Mache ich da was falsch, oder ist das normal so?
Es handelt sich um Einstellungen im Zweig HKLM\System. Mache ich da was falsch, oder ist das normal so?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 288331
Url: https://administrator.de/contentid/288331
Printed on: April 16, 2024 at 12:04 o'clock
15 Comments
Latest comment
Hi,
Einstellungen im HKLM\System sind vollkommen unabhängig vom Benutzer. Was soll also ein Benutzerlogin daran ändern?
Schlüssel fürs HKLM müssen in der Computerkonfiguration eingetragen werden. Die GPO muss dann für den Computer wirken, nicht für Benutzer. Der Computer muss seine GPO's updaten, nicht der Benutzer.
Was hast Du denn wo genau, wie eingetragen?
E.
Einstellungen im HKLM\System sind vollkommen unabhängig vom Benutzer. Was soll also ein Benutzerlogin daran ändern?
Schlüssel fürs HKLM müssen in der Computerkonfiguration eingetragen werden. Die GPO muss dann für den Computer wirken, nicht für Benutzer. Der Computer muss seine GPO's updaten, nicht der Benutzer.
Was hast Du denn wo genau, wie eingetragen?
E.
Ich bin mir zwar nicht sicher, ob das das ist, was du meinst, aber die Asynchrone Verarbeitung der Policys bei der Anmeldung könnte damit zusammenhängen.
Standardmäßig zieht sich Windows die Policys Asynchron. Das Beschleunigt den Login, weil der Benutzer nicht erst auf die Netzwerkverbindung warten muss. Aber wenn man eine Änderung an den Policys macht dauert es auch 2 Neustarts (manchmal auch länger) lange bis diese übernommen wird.
Solange du dich noch in deiner Testumgebung befindest solltest du die Policy für die Synchrone Verarbeitung setzen. Sobald du fertig bist, solltest du sie der Performance wegen deaktivieren
Richtlinien:
"Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" => Aktivieren
"Wartezeit für Richtlinienverarbeitung beim Systemstart angeben" => Eventuell Timeout von 30 Sekunden ändern (sollte aber nicht nötig sein)
Mehr Infos: GPO: Bei Anmeldung auf Netzwerk warten
Standardmäßig zieht sich Windows die Policys Asynchron. Das Beschleunigt den Login, weil der Benutzer nicht erst auf die Netzwerkverbindung warten muss. Aber wenn man eine Änderung an den Policys macht dauert es auch 2 Neustarts (manchmal auch länger) lange bis diese übernommen wird.
Solange du dich noch in deiner Testumgebung befindest solltest du die Policy für die Synchrone Verarbeitung setzen. Sobald du fertig bist, solltest du sie der Performance wegen deaktivieren
Richtlinien:
"Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" => Aktivieren
"Wartezeit für Richtlinienverarbeitung beim Systemstart angeben" => Eventuell Timeout von 30 Sekunden ändern (sollte aber nicht nötig sein)
Mehr Infos: GPO: Bei Anmeldung auf Netzwerk warten
@agowa338
Ich fürchte, Du verwechselst das mit der asynchronen Ausführung von Scripten. Alle GPO-Einstellungen, außer den Scripten, werden zwangsläufig immer "synchron" ausgeführt, sprich der Rangfolge nach, weil das gar nicht anders geht. GPO werden gar nicht einzeln angewendet, sondern immer nur deren Gesamtergebnis (RSOP = resultant set of policies), welches der Rangfolge der Policies entsprechend aufgebaut wird.
So wie der TO es aber schreibt, "beim zweiten Login", hat das aber nichts damit zu tun. Es sei denn der TO meint eigentlich "nach 2x booten".
Ich fürchte, Du verwechselst das mit der asynchronen Ausführung von Scripten. Alle GPO-Einstellungen, außer den Scripten, werden zwangsläufig immer "synchron" ausgeführt, sprich der Rangfolge nach, weil das gar nicht anders geht. GPO werden gar nicht einzeln angewendet, sondern immer nur deren Gesamtergebnis (RSOP = resultant set of policies), welches der Rangfolge der Policies entsprechend aufgebaut wird.
"Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" => Aktivieren
"Wartezeit für Richtlinienverarbeitung beim Systemstart angeben" => Eventuell Timeout von 30 Sekunden ändern (sollte aber nicht nötig sein)
Das ist richtig - beim Systemstart. Hier könnte dies dazu führen, dass neue oder geänderte GPO nicht sofort nach Systemstart angewendet werden, sondern erst beim nächsten GPupdate während der Laufzeit."Wartezeit für Richtlinienverarbeitung beim Systemstart angeben" => Eventuell Timeout von 30 Sekunden ändern (sollte aber nicht nötig sein)
So wie der TO es aber schreibt, "beim zweiten Login", hat das aber nichts damit zu tun. Es sei denn der TO meint eigentlich "nach 2x booten".
@emeriks
Nicht ganz, wir haben in der Firma langsame Netzwerkkarten. Deshalb wenden bei manchen die neuen GPOs nicht sofort angewendet.
Nach Aktivierung dieser Richtlinie müssen diese warten und die Richtlinien werden korrekt übernommen.
Außerdem gibt es GPOs für deren Anwendung keiner Angemeldet sein darf. Das Problem umgeht man so ebenfalls
Nicht ganz, wir haben in der Firma langsame Netzwerkkarten. Deshalb wenden bei manchen die neuen GPOs nicht sofort angewendet.
Nach Aktivierung dieser Richtlinie müssen diese warten und die Richtlinien werden korrekt übernommen.
Außerdem gibt es GPOs für deren Anwendung keiner Angemeldet sein darf. Das Problem umgeht man so ebenfalls
Zitat von @agowa338:
@emeriks
Nicht ganz, wir haben in der Firma langsame Netzwerkkarten. Deshalb wenden bei manchen die neuen GPOs nicht sofort angewendet.
Nach Aktivierung dieser Richtlinie müssen diese warten und die Richtlinien werden korrekt übernommen.
Ja, das ist doch ein alter Hut. Hat aber erstmal nichts mit diesem Fred zu tun.@emeriks
Nicht ganz, wir haben in der Firma langsame Netzwerkkarten. Deshalb wenden bei manchen die neuen GPOs nicht sofort angewendet.
Nach Aktivierung dieser Richtlinie müssen diese warten und die Richtlinien werden korrekt übernommen.
Selbst wenn der TO "2x booten" meinen sollte:
Wenn der Computer beim Booten nicht auf das Netzwerk wartet und deshalb eine GPO nicht anwendet, dann kann ich den Computer hundert mal hintereinander booten - er würde die GPO nicht anwenden. Es sei denn, ich warte vor dem Booten das nächste turnusmäßige GPupdate ab oder löse es selbst manuell aus.
Außerdem gibt es GPOs für deren Anwendung keiner Angemeldet sein darf. Das Problem umgeht man so ebenfalls
Ach ja? Und welche?
Sorry für die späte Antwort, es gab erst jetzt ne Benachrichtigung, dass eine Antwort da ist.
Zuerst mal, ich habe Einstellungen in HKLM\System im Benutzerteil der GPO gemacht, weil sich die Einstellungen je nach Benutzer unterscheiden. Dann wurde diese GPO standardmäßig "Alle Benutzer" zugeordnet (was nur mal zum testen so gelassen wurde). Außerdem wurde noch die Loopback-Verarbeitung eingeschaltet.
Der Effekt war, dass der Registryeintrag erst nach Ab- und wieder Anmelden aktiv war. Nachdem ich die GPO Computern zugeordnet hatte, war dieser Effekt tatsächlich weg. Allerdings wirkt sie so natürlich auf alle Benutzer an dem Rechner, was ja nicht so sein soll.
Eine echte Lösung habe ich noch nicht gefunden. Ich habe jetzt eine "Standardeinstellung", die für die meisten Benutzer gelten soll, festgelegt und eine weitere für einzelne Benutzer als erzwungen drüber gelegt. Leider wird diese drüber gelegte auch nach erneutem Login nicht übernommen. Auch die Reihenfolge der GPOs habe ich schon geändert, hat alles nix gebracht.
Am liebsten wäre mir, wenn Kyocera einen Treiber raus bringen würde, wo die Einstellungen im Benutzerbereich gespeichert würden. Aber leider sind die nicht zur Einsicht zu bewegen, dass das in manchen Fällen auch so gebraucht würde. Ich denke, da einen entsprechenden Treiber raus zu bringen, ware eine Minutenarbeit, da der Registrypfad ja nur unter nem anderen Zweig stehen müsste.
Zuerst mal, ich habe Einstellungen in HKLM\System im Benutzerteil der GPO gemacht, weil sich die Einstellungen je nach Benutzer unterscheiden. Dann wurde diese GPO standardmäßig "Alle Benutzer" zugeordnet (was nur mal zum testen so gelassen wurde). Außerdem wurde noch die Loopback-Verarbeitung eingeschaltet.
Der Effekt war, dass der Registryeintrag erst nach Ab- und wieder Anmelden aktiv war. Nachdem ich die GPO Computern zugeordnet hatte, war dieser Effekt tatsächlich weg. Allerdings wirkt sie so natürlich auf alle Benutzer an dem Rechner, was ja nicht so sein soll.
Eine echte Lösung habe ich noch nicht gefunden. Ich habe jetzt eine "Standardeinstellung", die für die meisten Benutzer gelten soll, festgelegt und eine weitere für einzelne Benutzer als erzwungen drüber gelegt. Leider wird diese drüber gelegte auch nach erneutem Login nicht übernommen. Auch die Reihenfolge der GPOs habe ich schon geändert, hat alles nix gebracht.
Am liebsten wäre mir, wenn Kyocera einen Treiber raus bringen würde, wo die Einstellungen im Benutzerbereich gespeichert würden. Aber leider sind die nicht zur Einsicht zu bewegen, dass das in manchen Fällen auch so gebraucht würde. Ich denke, da einen entsprechenden Treiber raus zu bringen, ware eine Minutenarbeit, da der Registrypfad ja nur unter nem anderen Zweig stehen müsste.
Zuerst mal, ich habe Einstellungen in HKLM\System im Benutzerteil der GPO gemacht, weil sich die Einstellungen je nach Benutzer unterscheiden.
Ich hatte zwar bis eben noch geglaubt, dass das nicht geht, aber ok, wieder was gelernt.Aber es handelt sich dabei nicht um einen TS? Falls doch, dann wäre das sowieso sinnlos.
Außerdem wurde noch die Loopback-Verarbeitung eingeschaltet.
Warum? Soll diese Einstellung nur auf diesem Computer vorgenommen werden?Und welchen Modus?
Du weißt, dass sich diese Einstellung nicht bloß auf diese GPO auswirkt sondern auf alle GPO, die über diesen Computer gesammelt werden?
Der Effekt war, dass der Registryeintrag erst nach Ab- und wieder Anmelden aktiv war.
Was dann aber nichts mit dem zwischenzeitlich aktiviertem Loopback zu tun hat.Nachdem ich die GPO Computern zugeordnet hatte, war dieser Effekt tatsächlich weg.
Du meinst, nicht bloß die GPO dem Computer zugeordnet sondern dann auch diese Einstellung statt in der Benutzerkonfiguration nun in der Computerkonfiguration vorgenommen? Falls nicht, dann hättest Du Dich selbst ausgetrickst.Leider wird diese drüber gelegte auch nach erneutem Login nicht übernommen. Auch die Reihenfolge der GPOs habe ich schon geändert, hat alles nix gebracht.
Ich nehme an, Du hast beim Erstellen des Eintrags als Aktion "Aktualisieren" gewählt. Wenn nur "Erstellen" dann wäre klar, dass das nicht geht.Am liebsten wäre mir, wenn Kyocera einen Treiber raus bringen würde, wo die Einstellungen im Benutzerbereich gespeichert würden. Aber leider sind die nicht zur Einsicht zu bewegen, dass das in manchen Fällen auch so gebraucht würde. Ich denke, da einen entsprechenden Treiber raus zu bringen, ware eine Minutenarbeit, da der Registrypfad ja nur unter nem anderen Zweig stehen müsste.
Aha. Jetzt kommen wir mal auf den Punkt. Vielleicht bis Du ja falsch unterwegs. Welche Einstellung ist denn das und hast Du schon mal im Forum zielgerichtet gefragt, wie man diese Einstellung bei diesem Drucker per Benutzer tätigen könnte?Aber es handelt sich dabei nicht um einen TS? Falls doch, dann wäre das sowieso sinnlos.
Keine Ahnung. Was ist ein TS? Sinnlos finde ich diese Einstellung jedenfalls nicht.Du weißt, dass sich diese Einstellung nicht bloß auf diese GPO auswirkt sondern auf alle GPO, die über diesen Computer gesammelt werden?
Jupps, genau das iste s auch was ich will. Diese Variante passt viel besser zur IT-Struktur.Du meinst, nicht bloß die GPO dem Computer zugeordnet sondern dann auch diese Einstellung statt in der Benutzerkonfiguration nun in der Computerkonfiguration vorgenommen? Falls nicht, dann hättest Du Dich selbst ausgetrickst.
Nein, die GPO bleibt völlig gleich, d.h. dort stehen die Einstellungen nach wie vor in der Benutzerkonfiguration. Die Zurodnung der GPO wird aber auf Computer festgelegt, was ja auch zur Vorgehensweise der Loopback-Verarbeitung passt.Ich nehme an, Du hast beim Erstellen des Eintrags als Aktion "Aktualisieren" gewählt. Wenn nur "Erstellen" dann wäre klar, dass das nicht geht.
Nein, "Ersetzen", weil eine andere Einstellung lässt er nicht zu, wenn man angibt, dass die Einstellung wieder gelöscht werden soll, wenn sie "außerhalb des Zuständigkeitsbereichs" liegt.Aha. Jetzt kommen wir mal auf den Punkt. Vielleicht bis Du ja falsch unterwegs. Welche Einstellung ist denn das und hast Du schon mal im Forum zielgerichtet gefragt, wie man diese Einstellung bei diesem Drucker per Benutzer tätigen könnte?
Nein, ich habe stattdessen bei Kyocera nachgefragt. Die haben mir auch bestätigt, dass es da keine Möglichkeit gibt. Ist auch klar, da die Einstellungen in der Registry unter HKLM gespeichert werden, was ich nicht immer als sinnvoll erachte. Was da eingestellt werden soll, ist die Art der Kostenstellenangabe und eventuell eine vorgegebene Liste zur Auswahl. Die meisten Nutzer werden zur Kostenstelleneingabe aufgefordert, was auch derzeit funktioniert. Manche Nutzer sollen aber stattdessen zur Einfachheit eine Liste angeboten bekommen, weil sie je nach Auftrag zu anderen Kostenstellen zuzuordnen sind. Klar, kann der Nutzer diese auch jedes Mal eintippen, aber wesentlich benutzerfreundlicher wäre eine Liste.Hier mal die Antwort von Kyocera:
Der KX-Treiber arbeitet nach den Windows-Standards, d.h. die Standardwerte des Druckertreibers werden unter HKLM abgelegt, User Einstellungen im Treiber unter HKCU.Keine Ahnung. Was ist ein TS? Sinnlos finde ich diese Einstellung jedenfalls nicht.
Sorry. Mit TS meine ich Terminalserver. Dort arbeiten i.A. mehrere Benutzer parallel. Hier wäre es nicht möglich/sinnvoll, Einstellungen im HKLM benutzerabhängig zu tätigen, weil sich alle parallel arbeitenden Benutzer nur genau ein HKLM teilen. Es sei denn, man arbeitet mit Sandboxen.Nein, die GPO bleibt völlig gleich, d.h. dort stehen die Einstellungen nach wie vor in der Benutzerkonfiguration. Die Zurodnung der GPO wird aber auf Computer festgelegt, was ja auch zur Vorgehensweise der Loopback-Verarbeitung passt.
Das funktioniert nicht. Eine GPO, welche Benutzereinstellungen verteilen soll, muss in der Sicherheitsfilterung Benutzer oder Benutzergruppen berücksichtigen. Da ändert Loopback überhaupt nichts dran. Eine GPO, welche nur Computer anwenden dürfen, welche aber Benutzereinstellungen verteilen soll, wirkt nicht auf Benutzer, welche sich an diesem Computer anmelden, auch nicht mit Loopback.Nein, "Ersetzen", weil eine andere Einstellung lässt er nicht zu, wenn man angibt, dass die Einstellung wieder gelöscht werden soll, wenn sie "außerhalb des Zuständigkeitsbereichs" liegt.
Ok. Dann muss aber sichergestellt sein, dass dieser Wert in der Registry schon drin steht, wenn diese Einstellung angewendet werden soll.Nein, ich habe stattdessen bei Kyocera nachgefragt. Die haben mir auch bestätigt, dass es da keine Möglichkeit gibt. Ist auch klar, da die Einstellungen in der Registry unter HKLM gespeichert werden, was ich nicht immer als sinnvoll erachte. Was da eingestellt werden soll, ist die Art der Kostenstellenangabe und eventuell eine vorgegebene Liste zur Auswahl. Die meisten Nutzer werden zur Kostenstelleneingabe aufgefordert, was auch derzeit funktioniert. Manche Nutzer sollen aber stattdessen zur Einfachheit eine Liste angeboten bekommen, weil sie je nach Auftrag zu anderen Kostenstellen zuzuordnen sind. Klar, kann der Nutzer diese auch jedes Mal eintippen, aber wesentlich benutzerfreundlicher wäre eine Liste.
OK. habe mir das eben mal bei unseren Kyoceras angesehen.Wäre es nicht eine Option, dass auch jene, welche die Kostenstelle eingeben sollen, diese einfach aus der Liste wählen? Warum diese Trennung?
Sorry. Mit TS meine ich Terminalserver. Dort arbeiten i.A. mehrere Benutzer parallel. Hier wäre es nicht möglich/sinnvoll, Einstellungen im HKLM benutzerabhängig zu tätigen, weil sich alle parallel arbeitenden Benutzer nur genau ein HKLM teilen. Es sei denn, man arbeitet mit Sandboxen.
Achso, also lautet die Antwort Ja, es arbeiten mehrere Personen an einem Rechner, bzw auch eine Person an unterschiedlichen Rechnern.Das funktioniert nicht. Eine GPO, welche Benutzereinstellungen verteilen soll, muss in der Sicherheitsfilterung Benutzer oder Benutzergruppen berücksichtigen. Da ändert Loopback überhaupt nichts dran. Eine GPO, welche nur Computer anwenden dürfen, welche aber Benutzereinstellungen verteilen soll, wirkt nicht auf Benutzer, welche sich an diesem Computer anmelden, auch nicht mit Loopback.
Bei mir macht er es so, das ist auch exakt die Beschreibung von Microsoft, wie Loopback funktionieren soll.Ok. Dann muss aber sichergestellt sein, dass dieser Wert in der Registry schon drin steht, wenn diese Einstellung angewendet werden soll.
Das funktioniert jetzt mir der Filterung auf Computer auch. Allerdings eben nicht mit der GPO, die die Einstellungen überschreiben soll.OK. habe mir das eben mal bei unseren Kyoceras angesehen.
Wäre es nicht eine Option, dass auch jene, welche die Kostenstelle eingeben sollen, diese einfach aus der Liste wählen? Warum diese Trennung?
Nein, was wäre keine Option. Es handelt sich hierbei um ein Hochschullabor mit Forschungsinstitut. Die Studenten sollen nur in sehr wenigen Fällen (normalerweise 1 Termin pro Jahr) etwas für den Laborversuch drucken. Diese Kostenstelle ist auch in der Anzahl beschränkt, damit nicht wild gedruckt werden kann. Mitarbeiter und Tutoren haben eine, bzw. bei Mitarbeitern teilweise für mehrere Projekte mehrere Kostenstellen. Wenn nun immer eine Liste eingeblendet würde, würden alle Studenten die Begrenzung umgehen können. Deshalb sollen diese explizit zur Eingabe aufgefordert weden. Mitarbeitern möchte ich das natürlich gerne mit einer Liste ersparen.Wäre es nicht eine Option, dass auch jene, welche die Kostenstelle eingeben sollen, diese einfach aus der Liste wählen? Warum diese Trennung?
Achso, also lautet die Antwort Ja, es arbeiten mehrere Personen an einem Rechner, bzw auch eine Person an unterschiedlichen Rechnern.
Der Punkt ist, ob sie parallel arbeiten!!! Gleichzeitig via RDP oder ICA.Wenn sie nacheinander an einem Computer arbeiten, dann ist das eine ganz andere Übung.
das ist auch exakt die Beschreibung von Microsoft, wie Loopback funktionieren soll.
Nein, definitiv nicht. Ich habe das hier schon mal erläutert.Das funktioniert jetzt mir der Filterung auf Computer auch. Allerdings eben nicht mit der GPO, die die Einstellungen überschreiben soll.
Hier vermute ich den Fehler in Deinem - wie ich vermute - Missverständnis der Loopback-Verarbeitung.
Na ja, da steht genau das drin, was ich schreibe. Entweder meinst Du das Richtige, drückst Dich aber falsch aus, oder aber Du meinst das Falsche und machst es auch falsch und die Ergebnisse Deines Test sind nur das Resultat einer Selbsttäuschung.
Im von Dir verlinkten Artikel steht:
Loopback steuert nur den Vererbungspfad der GPO's. Es ändert nichts an der Filterung, sei es nun über die Sicherheitsfilterung, über WMI-Filter oder über die Zielgruppenadressierung.
Im von Dir verlinkten Artikel steht:
Der Computer aus der OU "Terminal Server" liest den Anteil Computerkonfiguration der Richtlinie "TerminalServer Einschränkungen".
Der Computer aus der OU "Terminal Server" liest den Anteil Computerkonfiguration der Richtlinie "Loopbackverarbeitungsmodus aktiviert".
Der Benutzer aus der OU "Meine Firma" liest den Anteil Benutzerkonfiguration der Richtlinie "Meine Std. Firmenvorgaben"
Der Benutzer aus der OU "Meine Firma" liest den Anteil Benutzerkonfiguration der Richtlinie "TerminalServer Einschränkungen"
Und jetzt erklär uns mal, warum es so sein soll/muss, dass eine GPO auf einen Computer angewendet werden soll/muss, damit die Benutzereinstellungen aus dieser GPO übernommen werden. Hm?Der Computer aus der OU "Terminal Server" liest den Anteil Computerkonfiguration der Richtlinie "Loopbackverarbeitungsmodus aktiviert".
Der Benutzer aus der OU "Meine Firma" liest den Anteil Benutzerkonfiguration der Richtlinie "Meine Std. Firmenvorgaben"
Der Benutzer aus der OU "Meine Firma" liest den Anteil Benutzerkonfiguration der Richtlinie "TerminalServer Einschränkungen"
Loopback steuert nur den Vererbungspfad der GPO's. Es ändert nichts an der Filterung, sei es nun über die Sicherheitsfilterung, über WMI-Filter oder über die Zielgruppenadressierung.
Ich hatte es ja schon oben geschrieben, warum diese GPO mit Benutzereinstellungen auf Computer beschränkt sein soll:
Wenn Kyocera einsehen würde, dass es durchaus auch sinnvoll sein kann, die Daten pro Benutzer zu speichern, wäre das alles kein Problem. Leider wollen die nicht. Ein Registry-Link wäre schön. Aber ich gleube sowas gibt es nicht.
Nein, was wäre keine Option. Es handelt sich hierbei um ein Hochschullabor mit Forschungsinstitut. Die Studenten sollen nur in sehr wenigen Fällen (normalerweise 1 Termin pro Jahr) etwas für den Laborversuch drucken. Diese Kostenstelle ist auch in der Anzahl beschränkt, damit nicht wild gedruckt werden kann. Mitarbeiter und Tutoren haben eine, bzw. bei Mitarbeitern teilweise für mehrere Projekte mehrere Kostenstellen. Wenn nun immer eine Liste eingeblendet würde, würden alle Studenten die Begrenzung umgehen können. Deshalb sollen diese explizit zur Eingabe aufgefordert weden. Mitarbeitern möchte ich das natürlich gerne mit einer Liste ersparen.
Wenn Kyocera einsehen würde, dass es durchaus auch sinnvoll sein kann, die Daten pro Benutzer zu speichern, wäre das alles kein Problem. Leider wollen die nicht. Ein Registry-Link wäre schön. Aber ich gleube sowas gibt es nicht.
Lass es gut sein. Wir reden aneinander vorbei.