Terminalserver - Computer sperren
Hallo. Ich habe einen Windows 2003 Terminal Server. Dieser wurde samt Richtlinien von irgendwem anderen eingerichtet, der nun nicht mehr erreichbar ist. Eine dieser Richtlinien besagt, dass die Funktion "Computer sperren" deaktiviert ist.
Nun die Frage: hat das einen technischen Grund? Ist diese Funktion möglicherweise aus logischen Gründen deaktiviert, weil zum Beispiel die Session aller User gesperrt wird oder so etwas in die Richtung? Oder kann ich die Richtlinie ohne Bedenken zu haben abschalten, sodass die Benutzer die Möglihckeit bekommen ihre Terminal-Sessionen zu sperren?
Danke für die Hilfe!
LG, Andy
Nun die Frage: hat das einen technischen Grund? Ist diese Funktion möglicherweise aus logischen Gründen deaktiviert, weil zum Beispiel die Session aller User gesperrt wird oder so etwas in die Richtung? Oder kann ich die Richtlinie ohne Bedenken zu haben abschalten, sodass die Benutzer die Möglihckeit bekommen ihre Terminal-Sessionen zu sperren?
Danke für die Hilfe!
LG, Andy
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 115467
Url: https://administrator.de/contentid/115467
Ausgedruckt am: 23.11.2024 um 09:11 Uhr
4 Kommentare
Neuester Kommentar
Moin,
wie soll dir im Forum jemand erklären warum das bei euch abgeschaltet wurde?
Es kann z.B. den Grund haben das gesperrte Sitzungen ja im Hintergrund weiter aktiv sind. Macht also ein User die Berechnung der Zahl "Pi" und sperrt die Kiste nur - dann verbrät dessen Session weiterhin resourcen ohne Ende...
Ebenfalls kann es Lizenztechnische Gründe haben -> indem ihr z.B. Personen-Lizenzen habt. Wenn ein User seine Session dann sperrt dann ist die Lizenz weiterhin "in use". Meldet er sich dann neu an und bekommt ne neue Session nutzt dieser User 2 Sessions - und somit habt ihr ggf. zuwenig Lizenzen...
Von daher kann das durchaus sein das es gute Gründe hat (wenn sperren deaktiviert ist dann kann der User sich nur abmelden oder seinen Rechner laufen lassen). das ihr nicht sperren dürft... DAS kannst nur du bzw. die EDV-Abteilung entscheiden...
wie soll dir im Forum jemand erklären warum das bei euch abgeschaltet wurde?
Es kann z.B. den Grund haben das gesperrte Sitzungen ja im Hintergrund weiter aktiv sind. Macht also ein User die Berechnung der Zahl "Pi" und sperrt die Kiste nur - dann verbrät dessen Session weiterhin resourcen ohne Ende...
Ebenfalls kann es Lizenztechnische Gründe haben -> indem ihr z.B. Personen-Lizenzen habt. Wenn ein User seine Session dann sperrt dann ist die Lizenz weiterhin "in use". Meldet er sich dann neu an und bekommt ne neue Session nutzt dieser User 2 Sessions - und somit habt ihr ggf. zuwenig Lizenzen...
Von daher kann das durchaus sein das es gute Gründe hat (wenn sperren deaktiviert ist dann kann der User sich nur abmelden oder seinen Rechner laufen lassen). das ihr nicht sperren dürft... DAS kannst nur du bzw. die EDV-Abteilung entscheiden...
Naja - ein User kann den anderen sicher nicht aussperren (würde mich wundern -> MS macht zwar gern mal nen Fehler bei der Überlegung - aber SOLCHE Schnitzer würden sofort behoben werden da sich die Leute reihenweise beschweren würden ;) )
Es kann aber halt bei den Usern selbst zu Problemen führen -> z.B. wenn die ihre Session nur vom ursprünglichen Terminal wiederherstellen dürfen UND nur ein Login zur Zeit erlaubt ist... Wird dann die Session gesperrt und der User geht an einen anderen Rechner hat er ein Problem...
Ich würde nicht unbedingt den Ansatz verfolgen "Erstmal Aktivieren und gucken ob es Probleme gibt". Sorry wenn ich das ganz hart ausdrücke - aber das ist für mich keine professionelle Arbeitsweise sondern Müll. Ich persönlich finde es nur in Ausnahmefällen akzeptabel etwas auszuprobieren und zu prüfen ob einer meckert oder nicht. IMO. soll die EDV die Arbeit der Leute unterstützen und beschleunigen - und nicht durch ein "Try & Error-Prinzip" die Angestellten als Versuchsobjekte nehmen... Ich würde auch jedem Admin der so vorgeht mal vorschlagen das er SEINEN Arbeitsplatz mal auch so behandelt: "Och, egal, ich drück mal drauf und gucke nach obs geht". Und selbstverständlich auch dann Rechenschaft darüber ablegt warum er seine Arbeit ggf. nicht geschafft hat... Denn bei einem normalen Büro müssen die Angestellten auch ihrem Vorgesetzten und ggf. den Kunden erklären warum es grad System-Probleme gibt (und sich den Unmut der Kunden anhören) -> nur DAVON bekommt man in der EDV eben nix mit...
Sinnvoller wäre der Ansatz zu prüfen warum die Einstellung so ist wie sie ist.
- Lizenzen vorhanden/Lizenzmodell?
- Anmeldebeschränkungen?
- Resourcenprobleme?
- ...
Erst wenn man alle diese Punkte geprüft hat und feststellt das in keinem dieser Punkte der Grund für eine Sperren-Sperre liegt DANN kann man den nächsten Schritt gehen und die Richtlinie ändern...
Es kann aber halt bei den Usern selbst zu Problemen führen -> z.B. wenn die ihre Session nur vom ursprünglichen Terminal wiederherstellen dürfen UND nur ein Login zur Zeit erlaubt ist... Wird dann die Session gesperrt und der User geht an einen anderen Rechner hat er ein Problem...
Ich würde nicht unbedingt den Ansatz verfolgen "Erstmal Aktivieren und gucken ob es Probleme gibt". Sorry wenn ich das ganz hart ausdrücke - aber das ist für mich keine professionelle Arbeitsweise sondern Müll. Ich persönlich finde es nur in Ausnahmefällen akzeptabel etwas auszuprobieren und zu prüfen ob einer meckert oder nicht. IMO. soll die EDV die Arbeit der Leute unterstützen und beschleunigen - und nicht durch ein "Try & Error-Prinzip" die Angestellten als Versuchsobjekte nehmen... Ich würde auch jedem Admin der so vorgeht mal vorschlagen das er SEINEN Arbeitsplatz mal auch so behandelt: "Och, egal, ich drück mal drauf und gucke nach obs geht". Und selbstverständlich auch dann Rechenschaft darüber ablegt warum er seine Arbeit ggf. nicht geschafft hat... Denn bei einem normalen Büro müssen die Angestellten auch ihrem Vorgesetzten und ggf. den Kunden erklären warum es grad System-Probleme gibt (und sich den Unmut der Kunden anhören) -> nur DAVON bekommt man in der EDV eben nix mit...
Sinnvoller wäre der Ansatz zu prüfen warum die Einstellung so ist wie sie ist.
- Lizenzen vorhanden/Lizenzmodell?
- Anmeldebeschränkungen?
- Resourcenprobleme?
- ...
Erst wenn man alle diese Punkte geprüft hat und feststellt das in keinem dieser Punkte der Grund für eine Sperren-Sperre liegt DANN kann man den nächsten Schritt gehen und die Richtlinie ändern...