MarcoW75

Hallo, wir haben eine Domäne auf Basis von Windows Server 2016 im Einsatz. Die meisten User arbeiten hauptsächlich mit Office 2019, einige User haben auch noch ein Programm zur Finanzverwaltung, andere zur Personalverwaltung oder auch mal irgendwelche Software für Architekten im Einsatz. Da ändert sich also nur selten was an der softwaremäßigen Ausstattung der Clients und außer Updates wird halt selten was Neues eingespielt. Allerdings beschäftigen die uns bei manchen Programmen schon recht umfangreich, weil nicht jedes Programm eine eigene Updatefunktion hat,sondern Patches etc. von manchen Herstellern nur als manuell zu installierende Datei bereitgestellt werden. Sprich: Da darf man dann als Admin an jeden Client-Rechner rennen,um das Update einzuspielen und ggf. die Admin-Zugangsdaten einzugeben, wenn das Programm diese erfordert (´ne Remote-Lösung ist erst in Planung...ist halt öffentlicher Dienst, da dauert die Genehmigung eine Ewigkeit). Nun, theoretisch könnte man die Updates per GPO verteilen (sofern die als msi-Datei bereitgestellt werden), die sich dann beim Login n die Domäne automatisch verteilt...das würde auch die Eingabe der Admindaten erübrigen. Und genau da beginnt mein Problem: Da ich das schon seit Jahren nicht mehr gemacht habe, habe ich es erstmal testweise auf einem einzelnen Windows 10-Client getestet und wollte testweise msi-Dateien von 7zip, FreeCommander und Filezilla so verteilen. D.h. User in eine OU gesteckt, 3 einzelne Gruppenrichtlinien (für jedes Programm eins) zur Softwareverteilung angelegt (die Installationsdateien liegen auf unserem Fileserver) und auf die OU angewendet. Ergebnis: von den 3 Programmen wird nur Filezilla installiert, die anderen beiden nicht. Testweise hab ich es dann auch nochmal mit den beiden Programmen probiert, die wir ursprünglich verteilen wollten, auch die wurden nicht installiert. D.h. von 5 Programmen, die per GPO installiert werden sollen, funktioniert es nur bei einem, obwohl die Einstellungen überall gleich sind. Testweise habe ich dann mal alle 5 zu installierenden Files in die GPO mit reingepackt, wo die Verteilung für Filezilla drinstand. Auch dann wird nur Filezilla installiert, der Rest nicht. Hat jemand eine Idee,wieso das nur bei einem von 5 Programmen funktioniert ? Interessant ist auch, dass ein gpresult /r auf dem Client anzeigt, dass auf ihn nur die Default Domain Policy wirken würde,obwohl die zur Installation von Filezilla ja nun definitiv auch angewendet wurde. Ach ja: einen weiteren Unterschied gibts noch: Wenn ich auf dem Server ein gpupdate /force mache und dann auf dem Client nochmal, dann kommt nur bei der GPO für Filezilla der längere Text, dass ein Geräteneustart für die Installation der Programme via GPO nötig ist...bei den anderen 4 kommt nur das obligatorische "Die Aktualisierung der Computerrichtlinie wurde erfolgreich abgeschlossen.".

Naja...da wir diverse Programme von Drittherstellern benutzen, klappt das mit der automatischen Umschaltung leider nicht bei allen Programmen, weswegen ich den schon aus purer Gewohnheit lieber manuell einschalte. @NorbertFe Ja, das Verhalten legen beide Admin-Accounts an den Tag. Testweise habe ich jetzt mal probiert, was denn passiert, wenn ich mich mit einem ganz normalen Benutzeraccount anmelde und dort z.B. versuche, die Druckereigenschaften zu ändern, was die normalen Benutzer ja auch dürfen. Funktioniert anstandslos. Auch wenn ich ein Programm dort deinstallieren will, reagiert Windows wie vorgesehen: es fragt mich nach den Zugangsdaten eines Admins und deinstalliert nach dessen Eingabe anstandslos. Sogar wenn es die Zugangsdaten desjenigen sind, dem die Deinstallation verweigert wird.

Hallo, wir stellen zur Zeit unsere ganzen Server von Windows Server 2012 auf Windows Server 2016 um. Bei den Servern, die als Terminalserver arbeiten, habe ich ein interessantes Phänomen feststellen können, vielleicht hat ja jemand hier eine Lösung. Ich habe 2 verschiedene Adminaccounts...einmal meinen eigenen Acount mit Adminrechten und den obligatorischen "Administrator"-Account. Um ein Programm für alle Terminalservernutzer nutzbar zu machen, muss ich diesen vor der Installation des Programmes in den Installationsmodus schalten (change user /install). Installiere ich das Programm dann, kann ich es anschließend zwar starten, aber z.B. keine Änderungen mehr am Programm vornehmen oder es gar deinstallieren. Denn dann bekomme ich die Meldung, dass ich dazu keine Berechtigung hätte. Auch andere Windows-Funktionen in Zusammenhang mit dem Programm (z.B. das Ändern von Druckereinstellungen) funktionieren nicht. Wechsle ich nun in den anderen Adminaccount, kriege ich keine derartige Meldung und kann mit dem Programm wieder machen, was ich will....Einstellungen ändern, deinstallieren usw. Sprich: Was ich mit Account 1 installiert habe, kann ich nur mit Account 2 ändern/deinstallieren und umgekehrt. Es macht also irgendwie den Eindruck, als sperrte sich jeder Admin-Account selbst von der weiteren Administration des Programmes aus. Testweise hab ich mal probiert, ob das auch passiert, wenn ich so ein Programm NICHT im Installationsmodus installiere,sondern im normalen Ausführungsmodus...selbes Spiel, daran liegts also offenbar nicht. Weiß jemand,warum Windows so reagiert ?

Ein vergleichbares Problem haben wir auch mit diesem Programm, interessanterweise nur bei einem der Backupaufträge. Eigentlich ist der so konfiguriert, dass er 2x pro Woche ein Vollbackup machen soll und an den restlichen Tagen jeweils ein inkrementelles Backup. Nun, die Vollbackups werden anstandslos gemacht, aber bei den inkrementellen Backups schlägt der Auftrag jeweils mit der Meldung fehl, dass kein Vollbackup existieren würde, auf das sich das inkrementelle Backup beziehen könnte.

Hallo, folgendes Problem: wir haben eine Netzwerkfreigabe auf unserem Fileserver, die quasi als Sammelbecken für gemeinsame Dateien aller Nutzer dient. Von Blankformularen bis hin zu irgendwelchen Fotos der letzten Firmenfeier, aber nichts wirklich Vertrauliches. Alles in einer schönen Ordnerstruktur je nach Abteilung sortiert. Auf diese Freigabe hatte bislang jeder User Vollzugriff, was nun geändert werden soll. Die User sollen in Zukunft zwar noch überall lesen können, aber nur noch in die Ordner reinschreiben können, die sie für ihre Arbeit brauchen. Nun, das über die Rechtevergabe umzusetzen, ist kein Problem. Was eher ein Problem ist: überhaupt erstmal rauszufinden, wer eigentlich in welchen Ordner schreiben können soll. Sowas weiß nur der Chef, der sich nur zu gerne davor drückt, das mal schriftlich festzuhalten (Dokumentation war bisher für ihn ein Fremdwort). Da es bei über 100 Usern und etlichen Programmen, die diese Freigabe nutzen, eine Mordsarbeit wäre, die User einzeln zu befragen, worauf sie zugreifen müssen, habe ich überlegt, ob es nicht machbar wäre, einfach mal die laufenden Schreibzugriffe auf die Freigaben zu überwachen und entsprechend auszuwerten. Keine Panik, es geht mir nicht darum, WAS die da ablegen,sondern nur darum, wer überhaupt in welchen Ordner schreibt. In den Sicherheitseinstellungen des Freigabeordners gibts zwar den Punkt "Überwachung", dort habe ich momentan testweise nur mich selbst eingetragen und lasse loggen, wenn das Erzeugen/Ändern/Löschen von Dateien und Ordnern gelingt bzw fehlschlägt. Aber wo bitteschön kann ich sehen, was da geloggt wird ? In der Ereignisanzeige des Fileservers, we Freigabe liegt, sind keine Einträge vorhanden. Bin ich da auf dem Holzweg ? Gibts noch eine andere Möglichkeit, die Schreibzugriffe auf die Netzwerkfreigabe zu dokumentieren ? Ach ja: Der Fileserver läuft mit Windows Server 2012 R2.

Ganz so verwunderlich finde ich das nicht. Bei uns in der Firma haben einige kleine Abteilungen nur einen allgemeinen Login für die dort tätigen Mitarbeiter. Wenn es nur einen Rechner in der Abteilung gibt, reicht das ja auch. Das Problem, das der TO hat, kommt dann zum tragen,wenn es mehrere Rechner gibt, auf denen mehrere Mitarbeiter parallel arbeiten sollen. Ich kann nicht sagen, ob sich das bei Windows Server 2016 geändert hat, zumindest unter Windows Server 2012 R2 ist es in den lokalen Gruppenrichtlinien (gpedit.msc) einstellbar: Computerkonfiguration=>Administrative Vorlagen=>Windows-Komponenten=>Remotedesktopdienste=>Remotedesktop-Sitzungshost=>Verbindungen=>Remotedesktopdienste-Benutzer auf eine Remotedesktop-Sitzung beschränken=>deaktiviert Natürlich sollte man bedenken, dass man trotzdem gewissen Einschränkungen unterliegt: Wenn beispielsweise beide User die selbe Datei lokal öffnen und dran arbeiten wollen, wird das unweigerlich in die Hose gehen.

Ne...ich gehe bald. Passt ihm nicht in den Kram, wenn ihn regelmäßig einer darauf hinweist, dass man bestimmte Sachen nicht SO umsetzt, wie er das macht, also will er meinen Aufgaben künftig wieder selbst übernehmen. Mal schauen, wann der Laden in den Insolvenzveröffentlichungen auftaucht :-D

Leider ist das Portforwarding für RDP eine häufig genutzte Unsitte, um sich von jedem x-beliebigen Windows-Rechner auf einen RDP-Server einloggen zu können. Mein (bald Ex-)Chef hat selbst dann nicht von dieser Unsitte abweichen wollen, als ich ihm mal die Ereignisanzeige eines so "angegriffenen" Servers gezeigt habe und 2 dieser Angriffe sogar Erfolg hatten. Aber er weiß ja sowieso alles besser.

Die o.g. Größen sind die Größenangaben, wie sie direkt auf dem Server angezeigt werden,d.h. in den 108GB sind die ganzen einzelnen Benutzerordner enthalten. Der Optimalfall wäre wohl, wenn man es hinkriegt, dass die User für ihr persönliches Netzlaufwerk nicht mehr die Größe der Partition des ganzen Fileservers angezeigt kriegen,sondern nur noch die aktuelle Belegung ihres eigenen Ordners in Relation zum Kontingent.

Hallo, vielen Dank für Eure Antworten. Ja, die 3 Netzlaufwerke liegen alle auf dem gleichen physischen Laufwerk des Servers. Netzlaufwerk 1 ist aktuell mit 108GB gefüllt Netzlaufwerk 2 hat aktuell 88GB. Netzlaufwerk 3 hat 44GB. Bei Laufwerk 2 und 3 gibts keine Größenbeschränkung für diese Freigaben , da würde ich es auch noch verstehen, wenn dort einfach der Platz der ganzen HDD des Servers angezeigt wird. Auf Laufwerk 1, wo die ganzen Benutzerlaufwerke liegen, gibts aber pro Person ein Kontingent von 2GB. Das wirkt auch, ich hab versucht, mehr in so eine Laufwerk zu packen als erlaubt...ging nicht. Zumindest dort sollte den Usern doch nur der gemäß Kontingentseinstellungen noch zur Verfügung stehende Platz angezeigt werden,oder ? Interessant auch: Wenn ich die Freigabe per Net use einbinde (wie es das Login-Script gemacht hat), wird mir für die Laufwerke keine Größe angezeigt.

Hallo, bei uns hat jeder User ein persönliches Netzlaufwerk, das als Laufwerk I: eingebunden ist. Zusätzlich gibts noch 2 weitere Netzwerkfreigaben auf dem Fileserver (Windows Server 2012 R2), die ebenfalls als Laufwerk eingebunden sind (Laufwerke L: und O:). Eingebunden wurde das bislang über ein Loginscript, das über die Default Domain Policy gestartet wird. Aus mir unbekannten Gründen,wird dieses Script aber manchmal beim Login nicht vollständig abgearbeitet,d.h. mal sind alle Laufwerke da, mal nur ein Teil, mal gar keins. Startet man das Script anschließend nochmal von Hand,werden die fehlenden Laufwerke anstandslos eingebunden. Funktioniert, ist aber nervig. Also hab ich das Script rausgeschmissen und durch eine eigene Gruppenrichtlinie ersetzt. Funktioniert auch zuverlässiger als die bisherige Methode mit dem Loginscript. Was mich etwas stört: aus irgendeinem Grund wird bei dieser Methode für jedes Netzlaufwerk die Größenangabe des Fileservers als vermeindliche Größe des Netzlaufwerkes angegeben. Sprich: Wenn ich in Windows auf "Dieser PC" klicke,sehe ich alle eingebundenen Laufwerke, aber die Netzlaufwerke haben alle die selbe Größenangabe und den selben Belegungsgrad , auch wenn diese Angaben natürlich nicht stimmen. Ansonsten kann man mit den Netzlaufwerken aber ganz normal arbeiten. Ist dieses Problem hier schonmal jemandem begegnet und gibts vielleicht eine Abhilfe ?

Habs etwas anoymisiert. Gerade nochmal gekuckt. Die Abweichung zwischen der Zeit auf dem DC und dem TC beträgt nur 6 Sekunden. Dürfte also kein Problem sein.

Hallo, ich habe mal wieder gleich 2 Probleme. Bei uns arbeiten die User mit Thin Clients auf verschiedenen Terminalservern. Insgesamt haben wir 2 Domänen. Auf Server Nr.1 läuft Windows Server 2008 R2. Heute morgen meldeten mir 2 User, dass die direkt nach dem Login noch kurz die "Willkommen-Ausschrift" von Microsoft sehen, danach erscheint "Zugriff verweigert". Also hab ichs mit anderen Accounts dieser Domäne probiert: z.T. klappt der Zugriff problemlos, z.T. gibts die gleichen Probleme. Natürlich hab ich mal gegoogelt, aber ich hab nicht wirklich was Erfolgversprechendes gefunden, wollte den Server auch nicht neu starten, solange es "nur" 2 User betrifft. Ich habs auch mal von meinem eigenen Rechner mit ihren Zugangsdaten probiert...gleiches Ergebnis. Die Ereignisanzeige zeigt nichts, was irgendwie auffällig aussieht: Ein Konto wurde erfolgreich angemeldet. Antragsteller: Sicherheits-ID: SYSTEM Kontoname: DSVSHLTS01$ Kontodomäne: DSV Anmelde-ID: 0x3e7 Anmeldetyp: 10 Neue Anmeldung: Sicherheits-ID: DSV\Carsten Kontoname: carsten Kontodomäne: DSV Anmelde-ID: 0x1289b8e Anmelde-GUID: {5ebc0e24-84c8-4011-597c-9ddc9cd2065b} Prozessinformationen: Prozess-ID: 0x1ef0 Prozessname: C:\Windows\System32\winlogon.exe Netzwerkinformationen: Arbeitsstationsname: DSVSHLTS01 Quellnetzwerkadresse: 192.168.110.200 Quellport: 49163 Detaillierte Authentifizierungsinformationen: Anmeldeprozess: User32 Authentifizierungspaket: Negotiate Übertragene Dienste: - Paketname (nur NTLM): - Schlüssellänge: 0 Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde. Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe". Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk). Die Felder für die neue Anmeldung geben das Konto an, für das die Anmeldung erstellt wurde, d. h. das angemeldete Konto. Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben. Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung. - Die Anmelde-GUID ist ein eindeutiger Bezeichner, der verwendet werden kann, um dieses Ereignis mit einem KDC-Ereignis zu korrelieren. - Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren. - Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an. - Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0. und Einer neuen Anmeldung wurden besondere Rechte zugewiesen. Antragsteller: Sicherheits-ID: DSV\C.arsten Kontoname: carsten Kontodomäne: DSV Anmelde-ID: 0x1289b8e Berechtigungen: SeSecurityPrivilege SeTakeOwnershipPrivilege SeLoadDriverPrivilege SeBackupPrivilege SeRestorePrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeImpersonatePrivilege und Ein Konto wurde abgemeldet. Antragsteller: Sicherheits-ID: DSV\Carsten Kontoname: Carsten Kontodomäne: DSV Anmelde-ID: 0x128877e Anmeldetyp: 3 Dieses Ereignis wird generiert, wenn eine Anmeldesitzung zerstört wird. Es kann anhand des Wertes der Anmelde-ID positiv mit einem Anmeldeereignis korreliert werden. Anmelde-IDs sind nur zwischen Neustarts auf demselben Computer eindeutig. Weiß jemand, warum diese Fehlermeldung bei manchen Usern kommt und bei anderen nicht und wie ich das beheben kann ? -------------------------- Problem Nummer 2: Anderer Terminalserver (diesmal mit Win Server 2012 R2 drauf), andere Nutzerin. Die bekommt beim Loginversuch die Fehlermeldung, daß Zeit/Datumsangabe zwischen Server und Client abweichen. Auch hier ist es egal,von wo aus ich die Verbindung herstelle, sie ist förmlich an die Nutzerin gebunden, während diese FM bei anderen Usern ausbleibt. Unnötig zu erwähnen, dass die Uhrzeiten zwischen den Servern maximal um ein paar Sek abweichen,auch Datum und Zeitzone ist identisch. Weiß jemand,warum das nur bei einer Benutzerin der Fall ist und wie ich es beheben kann ?

Hallo, bei uns laufen (fast) alle Server virtualisiert auf einem VSX-Server. Das Backup findet mittels Veritas Backup Exec 15 statt,d.h. 1x pro Woche wird ein Vollbackup gemacht, und jede Nacht ein inkrementelles Backup. Da mein Chef ein Knauser vor dem Herrn ist, wird bei einigen Servern nicht mal der ganze Server gesichert, sondern nur die wichtigsten Dateien. Der Grund ist simpler Platzmangel: für Backups sind gerade mal 2 Platten a 500GB vorgesehen. Das ist ein Spiel mit dem Feuer. Eigentlich müsste er´s mittlerweile besser wissen, denn inzwischen hatten wir in 2 Jahren insgesamt 4 (!) Vorfälle, in denen irgendwelche Verschlüsselungstrojaner sämtliche persönlichen Dokumente (Texte, Exceltabellen, Bilder etc) auf den diversen Servern verschlüsselt haben und auf die kein AV-Programm reagiert hat. Bevor einer meckert...3 dieser 4 Vorfälle waren vor meiner Zeit dort in der Firma. Anhand der Position der verschlüsselten Dateien war zu erkennen,dass sich der Trojaner wohl von einer Netzwerkfreigabe zur anderen "vorgehangelt" hat...was nicht freigegeben war, wurde auch nicht verschlüsselt. Nachdem ich nun gestern damit verbracht habe, das Ding aufzuspüren und vom System zu schmeißen, gings ans Recovery der Dateien aus dem Backup. Leider ist das Recovery dieses filebasierten Backups sehr langwierig, zumal die Arbeitsweise von Backup Exec mit Backupserver und entsprechenden Agents auf den Servern nicht gerade zuverlässig ist (die Verbindung zwischen beiden bricht gerade bei der Wiederherstellung gerne mal ab). Wie wird das Backup bei euch durchgeführt ? Insbesondere habe ich ein gedankliches Problem damit, dass der Backupserver auch ständig im System hängt, weswegen ich unterschwellig die Befürchtung habe, dass irgendein Schadprogramm die Backups auch mal mit löscht.

Hallo, ich habe ein kleines Problemchen. Ab und an kommt es vor, dass 2-3 unserer User ihre Benutzerprofile auf einem der Terminalserver (mit WinServer 2012 R2) , auf dem sie arbeiten, "zerschießen". Üblicherweise äußert sich das zuerst daran, dass die Farben auf dem Bildschirm nicht mehr stimmen, manchmal lässt sich auch Outlook nicht mehr starten. Der Wechsel zu einem anderen Thin Client oder zu einem richtigen PC zeigt das gleiche Verhalten, andere User können aber an den Geräten der betroffenen Personen problemlos arbeiten. Üblicherweise behelfe ich mir dann damit, die wichtigen Daten aus deren Profilen zu sichern (eigene Dokumente, Desktopobjekte, Favoriten usw), den Profilordner zu löschen, die Registry zu bereinigen und sie sich neu anmelden zu lassen. Dabei wird dann ein neues Profil anlegt, in welches ich dann die gesicherten Dateien zurückschreibe. Dann läufts wieder für einige Wochen. Interessanterweise tritt das immer nur bei den gleichen 2-3 Usern auf, nie bei anderen. Bei einer lokalen Installation an einem Rechner kann sowas ja vorkommen, wenn man den Rechner einfach hart ausschaltet, aber bei einem Terminalserver können die User das ja glücklicherweise nicht. Hat jemand eine Idee, woran das liegen könnte ? Leider melden sie die Probleme oft erst Tage später, so dass es schwierig ist, dann noch was anhand der Ereignisanzeige herauszufinden.

Sorry, hatte versehentlich auf den Sendebutton gedrückt,bevor ich überhaupt mehr als die Begrüßung geschrieben hatte.

Hallo! Bei uns arbeiten die meisten User von ihren per VPN angebundenen Außenstellen via Thin-Clients auf Terminalservern in der Zentrale. In einer bestimmten Filiale meckern die User zur Zeit, dass die Verbindung zum Terminalserver grottenlangsam sei. Ich habs selbst vor Ort probiert, es ist tatsächlich grottig: Tastatureingaben werden erst 2-3sek nach Betätigung der Taste akzeptiert , der Seitenaufbau geschieht zeilenweise usw. Damit ist kaum ein vernünftiges Arbeiten möglich. Interessanterweise nur via Igel...hänge ich meinen Laptop dran, kann ich schön flüssig auf diesen Terminalservern arbeiten. Daher denke ich,dass vielleicht die Igel der Knackpunkt sind. Testweise habe ich mal einen Igel (UD2-LX40) auf Werkseinstellungen zurückgesetzt und ein neues Profil angelegt, welches eigentlich nur die Bildschirmauflösung, die Tastaturbelegung und und die Systemsprache anpasst,sowie eine RDP-Verknüpfung zum Terminalserver auf den Desktop des Igel legt. Es passiert, was man sich schon denken kann: damit läuft die Verbindung *merklich* flüssiger. Allerdings funktioniert diese Methode offenbar nur mit dem UD2-LX40. Die meisten User haben jedoch UD3-LX42 inkl. 2 Monitoren stehen. Die gleiche Methode funktioniert dort leider nicht im Geringsten,d.h. die Geräte lassen sich selbst mit so einem "Minimum-Profil" kaum bedienen,weil sie die oben schon genannten Probleme zeigen: Langsamer Seitenaufbau, verzögerte Eingabeerkennung usw. Hat jemand einen Tip, wie ich den Dingern sprichwörtlich "Beine machen" kann ? Gibts da irgendwelche empfohlenen Einstellungen ?

Irgendwie hat die Mouse wohl wirklich nen Knacks weggekriegt. Durch das abschalten der Daumentaste hab ich zumindest das Eingangs geschilderte Problem beheben können. Dafür find die Maus dann an, öfters mal hängenzubleiben,d.h. der Mauszeiger bewegte sich nicht mehr, die Tasten funktionierten aber noch. Wieder Kabelmaus angesteckt=>Zeiger wieder ok. Ich vermute,dass es auch was mit der Daumentaste zu tun hat (die Auflagefläche für den Daumen ist jedenfalls auch irgendwie "labil"). Ich werde mich heute nachmittag auf jeden Fall sicherheitshalber mal in den Elektronikmarkt meines Misstrauens begeben und vorsichtshalber Ersatz besorgen....die kleine Ersatz-Kabelmaus finden meine Riesen-Pranken nämlich nicht so toll.

Ah...danke für die Info, dann werd ich das mal tun. Ich muss gestehen, dass ich diese Taste bisher noch nie gebraucht hab (sie ist halt sehr unscheinbar).

Scheint wohl ein Problem mit der Mouse (Logitech MX Master) zu sein. Nachdem ich erst die Tastatur gewechselt hatte, das Problem aber blieb, habe ich testweise mal das Vollbackup von letzter Woche zurückgespielt (da war das Problem ja noch nicht da). Das Problem bliebt jedoch auch nach dem zurückspielen. Also konnte es kein Softwareproblem sein. Allerdings habe ich gemerkt, das das Problem scheinbar nur auftritt, wenn ich die Mouse nutze. MX Master abgeschaltet,dafür ne schnurgebundene HP-Maus angestöpselt...und schon war das Problem nicht mehr da. Das Problem hat sich also erledigt.

Hallo! In Windows 10 gibts die Möglichkeit, mit virtuellen Desktops zu arbeiten. Mit Win+Tab kann man neue virtuelle Desktops anlegen und dazwischen hin und herschalten. Irgendwie hab ichs hinkriegt,dass mein Rechner wiederholt ebendiese Funktion aufruft,d.h. in unregelmäßigen Abständen wechselt der Desktop zu genau diesem Fenster, das man auch sieht,wenn man Win+Tab-Taste drückt. Das ist extrem nervig. Hat jemand ´ne Ahnung, wie man das unterbinden kann ? Sonstige Funktionen, die mit den beiden genannten Tasten aufgerufen werden (etwa der Aufruf des Startmenüs oder auch das Springen von Feld zu Feld mit der Tab-Taste) funktionieren anstandslos, daher gehe ich nicht von eindem Defekt der Tastatur aus. Weiß jemand,wie man das abschalten kann oder was da überhaupt "reinstört" ? Den Autostart hab ich bereits aufgeräumt, d.h. da läuft kein Tool, welches dies auslösen könnte.

Mein erster Kontakt mit Computern war noch zu DDR-Zeiten mit einem KC85/3 in einer Computer-AG. Programme wurden noch auf Audiokassetten gespeichert. Jeden Samstagnachmittag saß ich wie gebannt vor dem Radio, weil der Berliner Rundfunk da eine Sendung ausstrahlte, in der auf diese Art meist Spiele via Radio übertragen wurden. Die Kassette ging dann am nächsten Donnerstag in der Computer-AG reihum, weil sie alle spielen wollten :-D Nach der Wende kaufte ich mir dann ´nen C64, die dann schon mit 5,25"-Floppy. Die Nummer, Disketten zu lochen kenn ich also auch noch. Später gings dann über einen Amiga 600 und einen A1200 zum ersten 486DX2-66Mhz weiter.

Vielleicht steh ich ein wenig auf dem Schlauch,aber ich probier das momentan via Gruppenrichtlinie. D.h. ich hab für jede Abteilung eine eigene OU, auf die dann eine Gruppenrichtlinie wirkt, die den Benutzern dieser OU einen bestimmten Standarddrucker zuweist. Das funktioniert auf einem Terminalserver jedoch nur, solange sich kein User einer anderen OU anmeldet, dabei wird sonst nämlich der Standarddrucker für *alle* Benutzer auf den Standarddrucker des Users eingestellt, der sich zuletzt am System eingeloggt hat. Will sagen: die Standardnutzereinstellung wirkt immer für alle an einem Terminalserver eingeloggten User.

Bei uns sind SMB-Verzeichnisse eingerichtet,d.h. die User können direkt vom Gerät in diese Freigaben "hineinscannen". Sie müssen eigentlich nur ihren Namen aus dem Adressbuch auswählen und die Starttaste drücken. Die Firma, die die Drucker eigentlich supportet (haben einen VPN-Zugang in unser Netz und auch ein eigenes AD-Konto), schaltet sich regelmäßig remote auf die Geräte drauf und wurstelt an diesen Einstellungen im Adressbuch rum, d.h. die ändern z.B. die im Adressbuch für jeden User eingetragenen Zugangsdaten mit Schreibrechten in ihre Benutzerverzeichnisse auf ihren eigenen AD-Account. Wäre ja nicht weiter schlimm...wenn die Zugangsdaten auch funktionieren würden. Tun sie aber nicht, was die Deppen auch merken würden, wenn sie nur ein einziges Mal den Testbutton direkt unter dem Eingabefeld des Passwortes drücken würden. Dann würden sie nämlich einen netten Verbindungsfehler angezeigt kriegen, was ihnen zu denken geben sollte. Weiß Gott, wie oft ich denen das schon mitgeteilt hab, dass sie entweder mal ihre Daten prüfen oder aber die Pfoten von den Einstellungen lassen sollen. Inzwischen gehört es mind. 1x wöchentlich zu meinen Standardaufgaben, die Drucker im Unternehmen auf derartige Veränderungen zu prüfen.

Hallo, wie ist das eigentlich bei euren Brötchengebern mit Fahrten zu Fortbildungen geregelt, was lange Fahrzeiten bzw die Erfüllung eurer vertraglichen Arbeitzeit angeht ? Wenn mich mein Chef an der Teilnahme einer Maßnahme verdonnert und verkündet, dass die 5h-Anreise am Vortag ist, wäre das bei Anreise mit dem eigenen Auto ja rechtlich gesehen Arbeitszeit. Habt ihr dann vorher nochmal für die restlichen Stunden nochmal zum Dienst zu erscheinen oder kriegt ihr kulanzweise den ganzen Tag als Anreise zur Verfügung gestellt ?