none
2x der gleiche angemeldete User per RDP bekommt unterschiedliche Defaultwerte in "Temporäre Internetdateien" RRS feed

  • Allgemeine Diskussion

  • Hallo zusammen,

    vorweg: Ich habe gesucht, aber nichts gefunden ;-)

    Folgendes Problem:
    wenn ich mich mit dem gleichen User 2x per RDP am gleichen Server anmelde, bekommt der 1.st User im IE->Internetoptionen->Browserverlauf/Einstellungen->Temporäre Internetdateien bei "Zu verwendeter Speicherplatz" den Defaultwert von 250 MB und "Aktueller Speicherort" = C:\Useres\xxx\Appdata\Local\Microsoft\Windows\INetCache\.

    Der 2.te User hat nur noch den Defaultwert von 0 MB (kann auf max. 8 MB geändert werden) und der "Aktueller Speicherort" = leer (es kann ein anderer gewählt werde, aber nicht der Default).

    Ist das normal, od. gibt es dafür eine Lösung?

    Um die Frage vorwegzunehmen:
    Dies betrifft einen externen Dienstleister, wo sich zeitweise 2-3 Personen gleichzeitig anmelden und jeder verschiedene Arbeiten ausführt.
    Diese müssen mit dem gleichen Account ausgeführt werden.
    Je nachdem, wird dazu der INetCache benötigt.

    Vielen Dank schon mal vorab für eure Tipps.

    Gruß Siggi

    Mittwoch, 6. März 2019 09:45

Alle Antworten

  • Moin,

    vermutlich eine IE-Steuerung per GPP mit einer Default-Vorgabe pro Server. Die GPPs werden bei einer zweiten Anmeldung auf der gleichen Maschine nicht mehr angewandt.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.


    Mittwoch, 6. März 2019 11:09
  • Vielen Dank für deinen Tipp, aber das war´s leider nicht.

    Wir haben alle GPO´s überprüft und keine entsprechende Policy/Einschränkung gefunden.

    Dazu kommt, das diese User Dom-User mit lokalen Adminrechten sind und von allen Beschränkungen ausgeschlossen sind.

    Vielleicht noch eine Idee ?

    Mittwoch, 6. März 2019 14:35
  • Moin,

    also auf einem Server 2016, wo *wirklich* keine GPOs angewandt werden, tritt das Verhalten nicht auf, soeben getestet.

    Du solltest wirklich GPRESULT und die Protokolle der GPO-Anwendung untersuchen. Zusätzlich könntest Du ProcMon in der zweiten Session bemühen und schauen, ob er die Registry gelesen kriegt. Vielleicht läuft in der ersten Sitzung ein Prozess, der die NTUSER.DAT so gesperrt kriegt, dass die zweite Sitzung sie nicht einmal lesen kann.

    Wie weit ist UAC auf der Maschine eingeschaltet?

    Ist ein Antivirus installiert? Falls ja: Tritt das Verhalten auch auf, wenn man ihn deaktiviert?


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Mittwoch, 6. März 2019 21:42
  • Hallo erstmal,

    also GPRESULT hatten wir schon überprüft, aber nichts gefunden.
    ProgMon zeigt mir nicht mal in der ersten Sitzung die NTUSER.DAT, aber trotzdem funktionierts in der 1.st Sitzung.

    Die UAC steht auf der ersten Stufe. Aber auch ganz abgeschaltet bringt keine Änderung.
    TrendMicro Antivirenprog deaktivieren bringt auch nichts.

    Habe testhalber ProgMon mal auf meinem Win10 PC ausgeführt....da zeigt er auch die NTUSER.DAT.

    Ich habe vergessen zu erwähnen, daß es sich bei dem 2016 Server um eine VMWare Maschine handelt.

    Da das ganze aber auf einem 2008R2 Server (ebenfalls VMWare) funktioniert, dürfte dies wohl keine Rolle spielen.

    Dazu folgender Test:
    Ich melde mich mit dem gleichen Dom-User-Konto für den 2008er Server am 2008er Server 2x Remote an und beide Sitzungen erhalten die entsprechenden Einstellungen.

    Nun melde ich mich mit dem gleichen Konto am 2016er Server 2x Remote an und ich habe wieder das gleiche Problem:
    1.st Remotesitzung erhält die Einstellungen, die 2.te Sitzung nicht.


    Umgekehrter Test:
    Ich melde mich mit dem gleichen Dom-User-Konto für den 2016er Server am 2008er Server 2x Remote an und ich habe das gleiche Problem:
    1.st Remotesitzung erhält die Einstellungen, die 2.te Sitzung nicht.

    Somit ist für mich klar, es kann nicht an den beiden Dom-User Konten liegen.

    Was ich noch erwähnen muß:
    Sowohl der 2008er Server als auch der 2016er Server sind Terminalserver.
    Sonst wären ja auch mehrfach Remoteverbindungen nicht möglich.

    Ich kann in beiden Terminalserver Konfigs keine entsprechende Einstellung finden, die evtl. für dieses Problem verantwortlich wäre.

    Hast du evtl. noch eine Idee? Mir sind sie ausgegangen...
    Ansonsten werde ich wohl einen externen Dienstleister beauftragen müssen.

    Gruß und schönes Wochenende.

    Samstag, 9. März 2019 15:26
  • Hallo,

    zuerst einmal habe ich quasi das gleiche Problem. Hier aber mit einem 2008R2 Std., dieser ist PDC und Terminal Server. Der läuft auch nicht auf einer VM. Außerdem scheint es unabhängig von der Mehrfachanmeldung der Benutzer zu sein, sondern eher daß irgendwann ein "Speicher überläuft" !?

    Was zumindest geholfen hat, ist die Einstellung des Kompatibilitätsmodus in der lokalen Sicherheitsrichtlinie. Dies greift aber nicht für andere Programme als den IE, die den Cache verwenden.

    Gibt es mittlerweile eine Lösung oder weiter Erkenntnisse?

    Gruß Micha


    • Bearbeitet Micha2810 Montag, 13. Mai 2019 23:05
    Montag, 13. Mai 2019 13:19