wolfgangbeyer

Hallo zusammen, das Problem hat sich gelöst. Der Benutzer hatte zuvor noch eine Verbindung über Computer / Netzwerkadresse hinzufügen der Art \\(Server)\(Freigabe) hergestellt also ohne Drive-Buchstaben-Zuordnung. Diese Verbindung wird per net use * /d /y offenbar nicht gelöscht. Nach manuellem Löschen im Explorer trat das Problem nicht mehr auf. Danke für die Tipps!

Hallo Günther, der Benutzer gibt beim Verbinden mit der Serverfreigabe seinen Domänen-Benutzer-Account an, dessen Name sich von dem seines lokalen Accounts auf dem Client unterscheidet.

Hallo, wir betreiben einen Domänenserver Win 2008 R2 mit XP-Clients. Manche dieser Clients befinden sich nicht in der Domäne, sondern der lokale Benutzer verbindet Freigaben auf den Server mit Laufwerksbuchstaben. Mit Clients unter Windows 7 scheitert nun dieser Schritt oft mit der Fehlermeldung "Dieser Netzwerkordner ist zurzeit unter Verwendung eines anderen Namens und Kennwortes verbunden". Es sieht so aus, als würde das insbesondere dann passieren, wenn man bereits eine Freigabe auf diese Weise verbunden hat, und nun zusätzlich eine andere mit einem anderen Laufwerksbuchstaben verbinden will, was unter XP gar kein Problem ist. Woran kann das liegen? Ich habe von 2K8R2 und Win 7 wenig Ahnung und wäre für jeden Hinweis dankbar.

Hi, ich muss mich gerade notgedrungen mit Policies, speziell mit SMB-Richtlinien, beschäftigen, habe davon aber wenig Ahnung. Daher folgende leichte(?) Grundsatzfrage: Ich habe 3 Zugänge gefunden, diese Einstellungen anzusehen bzw. zu bearbeiten, nämlich: A: gpedit.msc / Computerkonfiguration / Windows-Einstellungen / Sicherheitseinstellungen / Lokale Richtlinien / Sicherheitsoptionen. B: gpmc.msc / Domänen / (Domäne) / rechter Mausklick auf Default Domain Policy / Bearbeiten / Computerkonfiguration / Richtlinien / Windows-Einstellungen usw. wie bei A. C: gpmc.msc / Domänen / (Domäne) / Domain Controllers / rechter Mausklick auf Default Domain Controllers Policy usw. wie bei B. Manchmal sehe ich bei allen 3 Zugängen verschiedene Werte, und bei manchen Zugängen sind Optionen ausgegraut. Was ist denn der Unterschied zwischen A, B, und C, und über welchen Zugang ändere ich diese Einstellungen vernünftigerweise?

Ja, ok, das mit dem Datenschutz kann man natürlich durch Verweis auf knallharte Regeln lösen, wobei den unbedarfteren Anwendern dann nicht immer klar sein dürfte, dass auch ihre gelöschten Daten restaurierbar sind, auch wenn das im was-weiß-ich-wieviel-seitigem Regelwerk zu PC und Netzwerk, das man Ihnen bei Job-Antritt in die Hand drückt, irgendwo steht. Aber neben Datenschutz gibt ja auch andere Anlässen für einen Bedarf nach Löschen dieser Dateien: Wir sind z. B. ein Forschungslabor wo im Rahmen bestimmter Experimente temporär gigabyteweise Daten anfallen können, die nach der Auswertung kurz danach nicht mehr benötigt werden. Selbst wenn der Experimentator immer wieder die selben Dateinamen für dieses Dateien verwendet, dann müllt er natürlich trotzdem den Bereich für die Schattenkopien voll. Da wäre es nicht schlecht, wenn man z. B. als Admin diese Schattenkopien löschen könnte. Primär würde mich daher durchaus interessieren, ob es diese Möglichkeit gibt oder nicht.

@iDiddi Die Bedürfnisse der Benutzer können ja völlig entgegengesetzt sein. Der eine will seine Daten sichern, der andere will sie irreversibel löschen und zwar so, dass sie auch vom Admin nicht mehr restauriert werden können. Das kann z. B. dann der Fall sein, wenn ein Mitarbeiter unsere Institution verlässt und es ihm plötzlich bewusst wird, dass es sich um sensible Daten handelt, aus welchen Gründen auch immer.

Hi, eine Antwort auf die ursprüngliche Frage, wie kann ich einzelne Dateien im Schattenkopiebereich löschen, würde mich allerdings doch interessieren. Und zwar aus Gründen des Datenschutzes, wenn man z. B. eine Datei so löschen möchte, dass sie nicht ohne weiteres wieder restauriert werden kann. An sich würde mich das für Windows Server 2008 R2 interessieren, aber die Antwort dürfte ähnlich ausfallen, falls es eine gibt.

Meine Nachfrage hat ergeben, dass 255.255.255.0 die korrekte Subnetzmaske ist, 255.255.0.0 ginge aber auch, da sich der Router darum kümmere. Wie erwähnt, sehe ich bei beiden Einstellungen auch keinen Unterschied im Verhalten. Interessant dürfte aber sein, dass auch der Zugriff vom Server auf den Client mittels Explorer und \\(Client-IP)\C$ nicht funktioniert. Ich bekomme nach ewiger Warterei „Auf \\(Client-IP)\C$ kann nicht zugegriffen werden. Sie haben evtl. keine Berechtigung, diese Netzwerkresource zu verwenden. ...". Vom Client zum Server und von Client zu Client gibt’s keine Probleme, also genauso wie bei msg.exe. Könnte das ein Hinweis auf die Ursache sein?

Dort befindet sich laut meiner kürzlichen Anfrage bei den Betreibern des Teiles des Netzes, das sich außerhalb unseres Gebäudes befindet, ein Router. Daher mein vielleicht etwas missverständliches "angeblich". Ich werde nochmal nachfragen. 255.255.255.0 funktioniert jedenfalls auch nicht, wie ich kürzlich schon ausprobiert hatte.

Nein, offen gestanden habe ich kaum Ahnung von Netzwerkstrukturen. Die Adressen der XP-Clients stimmen bis auf die 4. Stelle überein, der Server hat allerdings auch eine andere 3. Stelle und steht in einem anderen Gebäude. Auf dem Weg dorthin befindet sich angeblich ein Router. Was wären für diesen Fall denn die angemessenen Subnetzmasken?

Es gibt neue Erkenntnisse: Es funktioniert im Prinzip in 70% der Fälle doch auch von Win 2008 nach XP, die Nachrichten werden dabei aber erst mit bis zu 18 Min. Verzögerung zugestellt, und nur in seltenen Fällen innerhalb von Sekunden! Bei den restlichen 30% steigt msg.exe nach 3 bis 13 Min. aus, meist mit einer der Fehlermeldungen: Fehler 1722 beim Abrufen der Sitzungsnamen Fehler 1726 beim Abrufen der Sitzungsnamen Fehler 1727 beim Abrufen der Sitzungsnamen Fehler [1726]: Der Remoteprozeduraufruf ist fehlgeschlagen (sehr selten) Von XP zu XP und von XP zu Win 2008 geht, wie gesagt, alles problemlos in Sekundenbruchteilen. Firewall empfängerseitig ausschalten ändert übrigens ebenso wenig wie senderseitig msg.exe in der Firewall explizit erlauben. Typisch ist, dass msg.exe mit der Option /v (verbose) im Erfolgsfall nach z. B. 10 Min. senderseitig "Nachricht wird an Console gesendet" aussgibt, es dauert aber dann noch weitere 2 Min. bis sie wirklich erscheint. Was könnte da die Bremse sein? Wäre das damit eher eine Frage für die Rubrik Windows Forum — LAN & WAN?

Hallo Necron, inzwischen habe ich herausgefunden, dass sich zwischen Server und Clients ein Router befindet. Aus Deiner Antwort schließe ich, dass unterschiedliche Subnetzmasken dann nicht die Ursache des Problems sind, oder? Aber was käme denn noch infrage?

Was mir dazu noch auffällt: Auf den XP-Clients ist Subnetzmaske 255.255.0.0 eingestellt, auf dem Server 255.255.255.0. Kann das eine Rolle spielen? Ich kann leider im Moment aus verwaltungstechnischen Gründen nicht so einfach mal am Server eine andere Einstellung ausprobieren.

Hallo zusammen, Nachrichten verschicken per msg.exe funktioniert bei mir zwischen XP-Clients sowie von XP-Client zum Windows Domänen-Server 2008 R2 problemlos, vom Server zum Client erhalte ich aber die Meldung "Fehler 1722 beim Abrufen der Sitzungsnamen". Woran kann das liegen? Alle Einstellung, die meines Wissens nötig sind, habe ich eingestellt, d. h. HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\AllowRemoteRPC = 1 überall sowie auf Win 2008 Remotedesktop » Verbindungen nur von Computern zulassen, auf denen Remotedesktop mit Authentifizierung auf Netzwerkebene ausgeführt wird aktiv.