Jump to content

Mister_M

Members
  • Gesamte Inhalte

    22
  • Registriert seit

  • Letzter Besuch

Fortschritt von Mister_M

Contributor

Contributor (5/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • 1 Jahre dabei
  • 5 Jahre dabei!

Neueste Abzeichen

0

Reputation in der Community

1

Beste Lösungen

  1. Ah okay - vielen Dank. Da diese Ereignisse bei mir nicht zu finden sind, muss ich wohl erstmal die Überwachungsrichtline in den GPPs aktivieren.... Vielen Dank erstmal
  2. Halo zusammen, kann man irgendwo herausfinden, wer bzw. von welchem Computer aus ein AD-Benutzerkennwort geändert wurde? Bei einer Kennwortfalscheingabe wird ja ein Event generiert in dem auch der Computername drin steht von wo aus das falsche Kennwort eingegeben wurde. Gibt es das auch bei erfolgten Kennwortänderungen? Vielen Dank Mister_M
  3. Also über gpresult sehe ich auch nur, das meine GPO welche den Chrome startet, abgelehnt wurde, was ja auch korrekt ist. Eingestellt in der Richtlinie habe ich das ganze über "Benutzerkonfiguration\Richtlinen\AdmVorlagen\System/Anmelden\Diese Programme bei der Benutzeranmeldung ausführen". Aber, wie gesagt, diese Richtlinie scheint nicht zum Tragen zu kommen, trotzdem startet der Chrome sich. Sodele, ich hab jetzt mal per Hand den Eintrag aus der Registry gelöscht den die GPO wohl angelegt hat (Screenshot oben). Jetzt scheint es zu gehen...
  4. Hallo zusammen, ich habe bei einem User das Problem das beim Anmelden immer der Chrome gestartet wird. Es gibt zwar bei uns eine Gruppenrichtline die den Chrome beim Anmelden startet, diese wird aber bei dem bestimmten User nicht angwendet, setht auch auf dem DC in den "Gruppenrichtlinienergebnissen" unter "Abgelehnte Gruppenrichtlinienobjekte" so drin. Mittels "autoruns" habe ich aber rausgefunden das der Chrome doch über eine Gruppenrichtline gestartet werden muss. Kann ich irgendwie herausfinden welche Richtlinie genau das Programm startet? Kleine Ergänzung was ich grade noch herausgefunden habe: Mittels RSoP habe ich bei dem bestimmten Users nichts gefunden, bei einem anderen User bei dem die Chrome Richtline angewendet wird, steht auch unter "Benutzerkonfiguration\Administrative Vorlagen\System\Anmelden" der entsprechende Eintrag drin, so wie es sein sollte. Grüße Mister_M
  5. Hallo Pi314, bin grade über Deinen Beitrag gestolpert weil wir unter Exchange 2016 ein ähnliches Problem haben. Weisst Du noch ob/wie Ihr das Problem gelöst habt? Grüße Mister_M
  6. Die Sache ist halt extrem komisch. Ohne RDS_Zeug ist der Speed Top. Nach den RDS-Rollen geht der Speed bei den ersten beiden Benchmarks auf 360 & 200, bei dem dritten auf 400 und die beiden letzten auf 400 runter. Dann (erst) habe ich die Energieeinstellung auf "Höchstleistung" gestellt damit ich die oberen Benchmarks bekomme. Ich schau mir mal den Beitrag von "Jan" an, ob das bei uns zutrifft. Es geht mehr um das Verständnis warum die RDS-Rolle so einen Einfluss auf die Geschwindigkeit hat ohne da schon User angemeldet sind.
  7. Nein, auf dem TS läuft nur der ERP-Client. Dei Leute haben sich beschwert als ich bei den ersten beiden Benchmarks 200 MBps und bei den unteren drei 400 hatte. Das konnte ich lösen indem ich die Energieeinstellung auf "Höchstleistung" gesetzt habe. Mich interessiert vor allem warum die RDS Rolle den Server so extrem ausbremst, vor allem bei den drei unteren Benchmarks.
  8. Hallo zusammen, ich habe ein relativ massives Geschwindigkeitsproblem auf meinem Terminalserver (Server 2016 Standard). Mittlerweile habe ich die "Ursache" gefunden, aber ich hätte gerne noch die Lösung dazu, hoffe Ihr könnt mir helfen. Ohne installierte RDS-Rollen ist die Geschwindigkeit in unserem ERP-System normal, das spiegelt auch der erste Screensshot wieder. Sobald ich die RDS Dienste installiere (habe es jetzt mal aufgesplittet, erst den Lizenzserver, dann den Host), geht die Geschwindigkeit in den Keller. Habe das mit dem Programm "Diskspeed" messen können. Die Voraussetzungen sind alle die gleichen, es ist kein anderer User angemedlet etc. Warum geht die HDD Geschwindigkeit (es sind übrigens Server SSDs verbaut) so in den Keller? Grüße Mister_M
  9. Also, hier wie versprochen mal die Screenshots: Der Client/User bekommt die GPO auf jeden Fall ab. Ich werde mich dann jetzt mal mit dem debug logging beschäftigen ob ich da was rauslesen kann.
  10. Haken bei standarddrucker ist gesetzt, die Druckerverwaltung muss ich ja nicht deaktivieren, da Win7. Screenshots setze ich mal am Montag rein
  11. Aktuell habe ich nur Win7 Maschinen die diese GPO bekommen, es ist egal ob ich mich gleich anmelde oder nach zwei Stunden.
  12. Ich habe alle drei Varianten (Erstellen, Ersetzen, Aktualisieren) versucht, ändert nichts am Verhalten das der Drucker zwar verbunden wird, aber eben nicht als Standard definiert. Daher kann ich auch eine noch nicht hergestellte Netzwerkverbindung als Fehler ausschließen, auch wenn ich den User abmelde, und wieder anmelde, gibt es keinen Standarddrucker. Im Eventlog habe ich keinen Eintrag gefunden der mir erklären würde, warum der Standarddrucker nicht gesetzt wird. Es ist übrigens egal, welchen Drucker ich versuche als Standarddrucker zu setzen. Schiebe ich den User in eine andere Druckergruppe im AD damit er einen komplett anderen (Standard)Drucker bekommt, bekommt er den Drucker, aber - wieder ohne Standard. Es ist fast wie verhext. Wenn "Martin" da was zu sagen kann, wäre das natürlich auch klasse... Da will man ein Problem lösen, und schafft sich drei neue.....
  13. Das ändert nichts, es ist immer kein Drucker als Standard definiert.
  14. Sorry, überlesen, was meinst du mit "zweimal anmelden"? Also Anmelden (kein Standarddrucker vorhanden) - Abmelden - wieder anmelden?
  15. Wir haben aktuell noch kixtart in Verwendung, haben hier aber in Verbindung mit Win10 verschiedene Probleme die mit GPO nicht auftreten, daher der Grund auch die Drucker damit zu verteilen. Die Drucker müssen wir verteilen und setzen, hat verschiedene Gründe. Der Drucker wird ja auch verbunden, er wird nur nicht als "Standard" geetzt wenn sich er User am Rechner anmeldet.
×
×
  • Neu erstellen...