LigH

Wie schon erwähnt: Windows meldet, dass das Dokument aufgrund eines "Fehlers" nicht gedruckt werden kann. Ich möchte erstmal herausfinden, welcher Fehler das genau ist.

Meine erste Idee war, in der Ereignisanzeige nachzuforschen, welche Fehler zu diesem Zeitpunkt aufgezeichnet wurden.

Und wie auch schon erwähnt, habe ich dabei nur einen DCOM-Fehler in diesem Zeitraum gefunden. Und gehofft, dass sich vielleicht jemand an solche Arten von Fehlern erinnert. Hätte ja sein können, dass es MCSEs mit mehr Erfahrung in dieser Ecke von Windows gibt...

Ein genaues Datum kann ich nicht nennen, ist aber schon einige Monate her. Man kann ja nicht stundenlang herumbasteln, während die Kollegen daran arbeiten müssen...

Nur einen der Treiber zu installieren würde bedeuten, den anderen Drucker bzw. MFC nicht an diesem PC nutzen zu können, was aber eigentlich das Ziel ist, beide verwenden zu können. Das funktioniert auf anderen PCs ja auch noch. Und das funktioniert auf anderen PCs auch mit WSD-Treibern und über WLAN.

Mehr oder weniger zielloses Rumprobieren ist auch nicht die Lösungsstrategie, die mir hier vernünftig erscheint. Damit habe ich schon recht viel Zeit verbraucht. Ich hatte auf etwas mehr systematisches Vorgehen gehofft. Angefangen damit herauszufinden, welche Art von Fehler genau denn nun das Drucken verhindert. Am Ende sind vielleicht die Treiber an sich korrekt installiert, und eine andere Schnittstelle ist defekt (evtl. dank der halbjährlichen Windows-10-Funktionsupgrades im speziellen Ausnahmefall), dann wäre Neuinstallieren von Treibern auf Verdacht nur wieder zusätzliche Zeitverschwendung.

Zum Ereignisprotokoll fällt keinem was ein?

Die wurden beide schon mehrfach deinstalliert und wieder neu installiert. Auch mit dem Herstellerprogramm, das beim vollständigen Entfernen helfen soll.

Ich habe im Netzwerk einen Windows-10-PC, von dem aus schon einmal alles problemlos funktionierte. Nachdem einmal die Druckertreiber für zwei verschiedene Brother-Drucker neu installiert wurden, ist nun das Drucken von diesem PC aus nicht mehr möglich. Laut Diagnose sollen die Treiber korrekt installiert sein. Der relevante Drucker (mit WSD-Treiber, via WLAN erreichbar) kann konfiguriert werden, sein Webdienst lässt sich im Browser aufrufen. Wenn aber ein Druckauftrag erzeugt wird, kann dieser wegen eines "Fehlers" nicht gedruckt werden (Windows 10 erzeugt dann rechts unten eine Meldung als Popup).

Leider erkenne ich nicht, um welche Art von Fehler es sich handelt, was die Behebung natürlich erschwert. Wie sollte man hier nun systematisch vorgehen?

Bisher bin ich auf die Idee gekommen, in der Ereignisanzeige nachzuschauen. Das einzige Ereignis, das mir zum Zeitpunkt des Druckfehlers als relevant auffällt, ist aber nur eine DCOM-Warnung, deren Analyse beschreibt, dass die Ausführung der Immersive Shell für diesen Benutzer nicht erlaubt wurde. Wie wahrscheinlich mag da ein Zusammenhang sein? Immerhin wäre die Behebung dieses Fehlers recht aufwändig, und ein Zusammenhang mit dem Druckproblem für mich nicht offensichtlich (außer bei der Uhrzeit des Ereignisses).

Alle PCs verwenden die gleiche Hardware (wurde sogar untereinander ausgetauscht) und die gleichen Treiber (von der selben Treiber-CD).

Bitte auch bedenken: Die SSID des 5-GHz-Netzes wird erkannt. Es wird überhaupt versucht, sich zu verbinden. Ein falsches Kennwort wird als falsch erkannt. Das alles weist also für mich darauf hin, dass die unteren Ebenen der Netzwerkverbindung durchaus korrekt funktionieren.

In einem Gebäude befinden sich eine Telefonanlage mit Speedport-Router (ZyXEL 790) mit 2,4-GHz- und 5-GHz-Kanälen sowie eine Fritz-Box 3270 als Access Point nur mit 2,4-GHz-Kanal (5 GHz wurde hier deaktiviert wegen Kompatibilität zu b-Geräten).

Mehrere PCs, teils mit Windows 7 oder Windows 10, können sich an jedem der Netze wahlfrei anmelden, das 5-GHz-Netz wird bevorzugt. Nur bei einem der PCs mit Windows 7 wird beim Versuch der Anmeldung an das 5-GHz-Netz (WPA2) ein unspezifischer Verbindungsfehler gemeldet (Verbindungen mit den beiden anderen 2,4-GHz-Netzen funktionieren einwandfrei). Wird ein falsches Kennwort eingegeben, wird auch korrekt gemeldet, dass das Kennwort falsch ist. Zur Behebung des Problems schlägt Windows lediglich vor, den Router neu zu starten, weitere Vorschläge kommen nicht.

Hat jemand Ideen, welche Ursachen hier in Frage kommen, und Empfehlungen, wie man das Problem weiter eingrenzen könnte? ... Mir fällt zum Beispiel gerade ein, dass es wohl irgendwo noch eine Möglichkeit gab, die unterstützte Verschlüsselungstechnik (AES oder PSK) genauer auszuwählen.

Ja, danke, lesbar und auch irgendwie gleich vom Sinn und Zweck her verständlich. Sehr deskriptive Befehle, erinnert fast etwas an SQL-JOINs mit GROUPs, von Umfang und Struktur her. Auf jeden Fall reichlich Schlagworte zum Stöbern.

Wie sähe denn dann vergleichsweise ein Einzeiler für PowerShell aus, mit dem man alle vorhandenen Dateien nach dem Muster Text1_???.txt in Text1_Dummy3_???.txt mal eben schnell an der Kommandozeile umbenennen kann? So ein Beispiel würde mir sicherlich reichlich Syntax-Elemente liefern, nach denen ich dann weiter suchen kann. Und nein, das ist bei weitem nicht die einzige Aufgabe, die ich auf solche Art von Dateigruppen anwenden will, und die unterscheiden sich immer wieder...

Gut möglich; damit kenne ich mich aber überhaupt nicht aus. Da ist die Syntax ja grundlegend anders als in Batch.

OK, danke. Vielleicht schaffst du es auch noch, die überflüssigen Leerzeilen in den Code-Blöcken wieder zu entfernen, die jeder Bearbeitungsschritt da eingefügt hatte ... ich kann ja nun nicht mehr editieren.

In der Zwischenzeit habe ich noch mehr ausprobiert. Es gab im IRC den Tipp, die FOR-Schleife auf die Ausgabe von "DIR /B" anzuwenden; da kommt aber ebenso mehr im Ergebnis heraus als erwünscht, wie wenn ich direkt mit FOR maskiere. Dies nützte also auch nichts:

FOR /F "usebackq" %a IN (`DIR /B Text1_???.txt`) DO ECHO %a

Zur Problemlösung verwende ich mittlerweile TCC/LE x64 (Take Command Console - Light Edition). Die wäre konfigurierbar, falls man Dateimasken nicht nur auf die LFN, sondern auch auf die SFN vergleichen wollte; Standard ist dort aber, nur die LFN zu vergleichen. Der kostenlose Funktionsumfang genügt mir.

Wenn ich in einem Verzeichnis sehr viele Dateien habe (evtl. über tausend), die am Anfang ihrer Dateinamen übereinstimmen, sich aber nach etwa dem 5. Zeichen unterscheiden, dann kann ich mich nicht mehr darauf verlassen, dass für das Jokerzeichen '?' noch die Regel gilt, dass es für exakt ein Zeichen steht. Auch unter Windows nach Vista ist immer noch eine Kompatibilität für kurze Dateinamen (DOS 8.3) aktiv, die auch beim Test auf Übereinstimmung von Dateiname und Suchmuster angewendet wird.

Im Ergebnis kann es dann passieren, dass man z.B. in einer FOR-Schleife versucht, einen Befehl nur auf Dateien anzuwenden, deren Dateiname einer bestimmten Länge entspricht, indem man diese Länge mit einer entsprechenden Anzahl Fragezeichen vorgibt. Wenn das System dann aber die kurzen Dateinamen zum Vergleich heranzieht, wird auch das Suchmuster auf die Länge 8.3 gekürzt, und schon erscheinen auch solche Dateien als auf das Suchmuster passend, deren langer Dateiname viel länger ist als das ursprüngliche Muster.

Beispiel zum Nachstellen:

@ECHO OFF
ECHO Text1_Dummy1...
FOR /L %%a IN (0,1,9) DO FOR /L %%b IN (0,1,9) DO FOR /L %%c IN (0,1,9) DO ECHO %%a%%b%%c > Text1_Dummy1_%%a%%b%%c.txt
ECHO Text1_Dummy2...
FOR /L %%a IN (0,1,9) DO FOR /L %%b IN (0,1,9) DO FOR /L %%c IN (0,1,9) DO ECHO %%a%%b%%c > Text1_Dummy2_%%a%%b%%c.txt
ECHO Text1...
FOR /L %%a IN (0,1,9) DO FOR /L %%b IN (0,1,9) DO FOR /L %%c IN (0,1,9) DO ECHO %%a%%b%%c > Text1_%%a%%b%%c.txt
ECHO Text1_???
ECHO Text1_??? > Text1.txt
FOR %%a IN (Text1_???.txt) DO ECHO %%a >> Text1.txt

Ergebnis (gekürzt):

Text1_??? 
Text1_000.txt 
Text1_001.txt 
Text1_002.txt 
...

Text1_997.txt 
Text1_998.txt 
Text1_999.txt 
Text1_Dummy1_000.txt 
Text1_Dummy1_001.txt 
Text1_Dummy1_002.txt 
Text1_Dummy1_003.txt 

Wie lässt sich das nun verhindern? Kann man dafür sorgen, dass FOR ausschließlich die langen Dateinamen auswertet?

Es ist zwar möglich, das zukünftige Erzeugen von kurzen Dateinamen auf NTFS-Volumes zu verhindern:

fsutil behavior set disable8dot3 1

Nach einem Neustart kann man die schon vorhandenen kurzen Dateinamen auch löschen lassen:

fsutil 8dot3name strip /f /s C:

Allerdings wurde (auch hier) schon über Nebenwirkungen berichtet, z.B. Inkompatibilitäten in Netzwerkfreigaben (nun ja, möglicherweise nur mit heutzutage veralteten Windows-Versionen, aber wer weiß?), und Firmware von Consumer-Mediaplayern fiele mir dazu auch noch ein – bevor ich das anwende, würde ich da schon gern mehr wissen; vielleicht gibt es ja noch andere Methoden, dafür zu sorgen, dass ich einer Dateimaske aus Sicht eines Nutzers von langen Dateinamen vertrauen kann.

_

P.S.: Der Kommandozeilen-Interpreter von JPSoft (TCC, früher 4DOS / 4NT) ließ sich dahingehend konfigurieren. CMD wird so eine Möglichkeit wohl nicht bieten?

Offenbar kann man hier besser spot-ten als helfen. Dieser Umgangston wäre dann für mich auch kein deutlicher Anreiz, einen der Teilnehmer hier dafür auch noch bezahlen zu wollen. Such ich also lieber anderswo...

Die Anfahrtspreise steigen sicher auch mit der Entfernung, oder?

@ DocData: In der Altmark ist die Auswahl an ebensolchen Spezialisten aber arg dünn. Und der eine, den ich mittelbar finden konnte, "muss sich erstmal darüber schlau machen" ... Darfst mir aber gern jemanden in dieser Region empfehlen.

@ testperson: Nun ja, les ich mal, danke...

Immer noch keine Lösung in Sicht...

Mittlerweile hat jemand den Verdacht geäußert, dass vielleicht der Windows Server explizit nicht auf interne Ports 80 weiterleiten mag, aus Sicherheitsgründen. Also habe ich mal in den Geräten den HTTP-Port auf 8080 konfiguriert.

Auch damit keine Durchleitung.

Bleibt mir nur weiter zu hoffen, dass jemandem ein wirklich grundsätzlicher Fehler auffällt. Wie schon geschrieben, Netzwerkprotokolle aus WireShark kann ich gern bereitstellen.

Auch das Lauschen von beliebiger Adresse (netsh ... listenaddress=0.0.0.0 ...) half nicht.

Der IP-Hilfsdienst läuft auch (älterer Hinweis).

Firewall-Ausnahmen wurden hinzugefügt. Nützte aber auch nichts.

Darüber streiten, ob das eine gute Idee ist, kann man ja mit der Firmenleitung... letztendlich muss man als Angestellter aber deren Wünsche erfüllen.

Die Geräte sind korrekt konfiguriert, soweit ich beurteilen kann, haben NTP-Verbindung zum Stellen der Uhr und Zugriff auf Firmware-Updates, Gateway sollte also stimmen (192.168.0.1). Von innen nach außen klappt es also.

Im Intranet funktioniert der Zugriff per Webbrowser mit HTTP-Auth; ob HTTPS möglich ist, lässt sich immer noch klären, wenn erstmal das Routing klappt. Vielleicht brauche ich zusätzlich zur Portweiterleitung auch noch Firewall-Ausnahmen?

Um auf spezielle Geräte in unserem Netzwerk, die einen simplen Webserver integriert haben, über das Internet zugreifen zu können, müssen TCP-Portweiterleitungen eingerichtet werden, da dieser Anbieter keinen eigenen Dienst für eine von innen vorbereitete Verbindung anbietet. Mit ein wenig Hilfe unseres Internetproviders wurde bereits eine Gruppe von Weiterleitungen in einem Mikrotik-Routerboard eingerichtet, und mit Hilfe von Wireshark auf unserem Intranet-Server (WS 2012 R2) ließ sich auch nachweisen, dass Anfragen aus dem Internet an eine Dynamic-DNS-Adresse mit Port wie gewünscht über das Routerboard geleitet werden und mit gleichem Port am Server ankommen.

http://dynamic.dns:8171 => 192.168.88.1 (Router) => 192.168.88.252:8171 (Windows-Server, "Internet"-Interface)

Was bisher jedoch nicht funktioniert, ist die fortgesetzte Weiterleitung der TCP/HTTP-Anfrage über den Server an das jeweilige Gerät im Intranet (192.168.0.[170..179]).

http://dynamic.dns:8171 => 192.168.88.1 => 192.168.88.252:8171 -X- 192.168.0.1 (Windows-Server, "Intranet"-Interface) => 192.168.0.171:80

Bisher habe ich zwei Möglichkeiten versucht. Zum einen wurde in einem Beitrag, den ich im Internet entdeckt habe, die Verwendung der NetShell empfohlen, weil dies auch ohne Neustart des Servers sofort funktionieren solle:

for /L %%a in (170,1,179) do netsh interface portproxy add v4tov4 listenport=8%%a listenaddress=192.168.88.252 connectport=80 connectaddress=192.168.0.%%a
netsh interface portproxy show all

Ergebnis an der Konsole:

Abfragen auf ipv4:             Verbinden mit ipv4:

Adresse         Anschluss   Adresse         Anschluss
--------------- ----------  --------------- ----------
192.168.88.252  8170        192.168.0.170   80
192.168.88.252  8171        192.168.0.171   80
192.168.88.252  8172        192.168.0.172   80
192.168.88.252  8173        192.168.0.173   80
192.168.88.252  8174        192.168.0.174   80
192.168.88.252  8175        192.168.0.175   80
192.168.88.252  8176        192.168.0.176   80
192.168.88.252  8177        192.168.0.177   80
192.168.88.252  8178        192.168.0.178   80
192.168.88.252  8179        192.168.0.179   80

Ergebnis im Webbrowser: Verbindung fehlgeschlagen

Also diese Variante zurückgenommen ("netsh interface portproxy delete v4tov4 listenport=8%%a listenaddress=192.168.88.252" in for) und noch mal in der Server-Verwaltung manuell 10 Portweiterleitungen eingetragen:

Routing und RAS » IPv4 » NAT » Internet » Eigenschaften » Dienste und Ports » Hinzufügen: TCP; Eingehender Port = 817#; Private Adresse = 192.168.0.17#; Ausgehender Port = 80

Dann auch den Server neu gestartet (waren eh gerade Updates zu installieren).

Ergebnis im Webbrowser: Verbindung fehlgeschlagen

In beiden Fällen habe ich versucht, den Traffic beider Netzwerkschnittstellen gleichzeitig mit Hilfe von Wireshark 2.0.5 zu überwachen, und dabei festgestellt, dass bei einer Anfrage am "Intranet"-Interface gar kein Traffic aufkommt. Es wird also gar keine Weiterleitung durchgeführt, der Verbindungsversuch wird anscheinend abgewiesen. Leider kenne ich mich mit Netzwerkprotokollen nicht gut genug aus, um hier etwas interpretieren zu können, aber eine pcap-Datei könnte ich bereitstellen.

Vielleicht hat aber schon ohne diese jemand eine Idee, was ich vielleicht vergessen oder vertauscht habe.

Da es bis heute keine funktional gleichwertige Alternative gibt, muss ich heute leider immer noch Programme verwenden, die noch die uralte Variante des Shell-Dialogs für "Datei – Öffnen / Speichern unter..." aus Common Controls anzeigen. Der ließ sich noch nicht mal vergrößern, in der Detail-Ansicht sieht man gerade mal 6 Zeilen mit Dateinamen.

Am störendsten ist für mich aber die Standard-Auswahl für die darin dargestellten Tabellenspalten. Anstatt "Datum" (vermutlich das Erstellungsdatum der Datei) hätte ich lieber die Spalte "Änderungsdatum", und die Spalte "Markierungen" interessiert mich überhaupt nicht. Lässt sich das irgendwie anpassen?

Im normalen Explorer ist es ja ab Vista möglich, sich einen Ordnerinhalt anzuschauen, der überwiegend Dateitypen aus einer gewissen Gruppe enthält (z.B. alles Bilder, oder alles Videos), dort die beliebtesten Spalten für diese Typgruppe auszuwählen, und dann über das Menü Extras bei Ordnereigenschaften den Standard für alle Ordner dieser Typgruppe festzulegen. Das scheint aber diesen Dialog im alten Stil nicht zu kümmern (oder ich weiß nicht genau, welche Typgruppe der als Standard-Vorlage benutzt).

Ich habe einen Server 2012 R2 als NAT-Server, der auch DNS-Relay durchführen soll, also sollten alle im Netzwerk angeschlossenen Windows-7-Arbeitsstationen funktionieren, wenn die LAN-IP des Servers als DNS-Server eingetragen ist. Meist funktioniert das, aber ab und zu eben auch nicht...

So habe ich z.B. ein Batch-Skript, das per wget dutzendfach Dateien aus eigentlich sehr bekannten Webserver-Clustern (wie SourceForge oder Github) herunterladen soll; fast immer gibt es dann mal einen Zugriff, bei dem das DNS für solche Server plötzlich versagt, obwohl direkt davor noch ein Zugriff auf eine sehr ähnliche Adresse funktioniert hat.

Habe ich auf den Arbeitsstationen die IP des externen DNS-Servers unseres ISP eingetragen, gibt es solche Fehler nicht.

Gibt es da Möglichkeiten, die Zuverlässigkeit zu verbessern, wenn man dennoch den LAN-Server als primären DNS-Server bevorzugen will/muss?

Im Windows-Explorer und allem, was mit der grafischen Shell zusammenhängt, kann man Programme per Rechtsklick aus dem Kontextmenü "Als Administrator ausführen". Dabei geht es weniger um Benutzer und Benutzergruppen mit solchen Namen, sondern um die "Benutzerkontensteuerung" UAC und die Ausführung mit den Rechten einer höheren Klasse (elevated privileges).

Aus guten Grund erscheint bei einem solchen Versuch eine Sicherheitsabfrage. Für Benutzer, die der Gruppe der Administratoren angehören (also ein administratives Benutzerkonto haben) genügt ein Klick auf einen "Ja"-Button, bei Benutzern mit eingeschränktem Benutzerkonto muss dafür stellvertretend die Anmeldung eines administrativen Nutzerkontos eingegeben werden.

Was mir in Windows bisher fehlt, ist die Möglichkeit, auch an der Eingabeaufforderung oder in Batch-Dateien einzelne Programme mit erhöhten Rechten ausführen zu können, auch wenn ansonsten der aufrufende Kommandointerpreter nicht selber mit erhöhten Rechten läuft. Ich möchte dafür also nicht gleich die cmd.exe (oder PowerShell oder den Far manager usw.) "als Administrator ausführen", sondern nur ab und zu mal einen Befehl entsprechend durch Eintippen oder im Verlaufe einer Batch-Sequenz mit erhöhten Rechten ausführen. Meinetwegen darf dafür gern der UAC-Dialog erscheinen, soll er ja auch.

Es gibt eine ganze Reihe Vorschläge, dies mit runas.exe und dem Start als Benutzer "Administrator" zu tun. Nur hat das mehrere Haken: Erstens darf sich der Benutzer "Administrator" (aus gutem Grund) sicherlich meist nicht interaktiv anmelden, außer vielleicht im "Abgesicherten Modus", und deshalb wird wohl in meinen Versuchen auch immer ein derartiger Aufruf verweigert:

runas [...] /user:administrator program

Zweitens bedeutet das Ausführen unter einem administrativen Benutzerkonto trotzdem nicht grundsätzlich, dass damit auch erhöhte Rechte erteilt werden. Und drittens sollte man das Passwort des "Administrator"-Kontos gar nicht wissen...

Ein CLI-Programm mit der Funktion "starte ein Programm mit administrativen UAC-Rechten" ist mir von Microsoft bisher nicht bekannt. Es geht wohl lediglich anders herum:

runas /trustlevel:Standardbenutzer program

In aktuellen Linux-Distributionen gibt es die sudo-Methode, bei der Mitglieder einer Gruppe von Super-Usern (sudoers) berechtigt sind, mit ihrem eigenen Passwort über den Befehl sudo die Befehle auszuführen, für die man sonst die Rechte des Nutzers root benötigt. So etwas gibt es zwar auch für Windows, aber das wäre noch mal eine zusätzlich zu installierende Verwaltungsebene. Die UAC reicht dafür aus, man bräuchte eigentlich nur ein Kommando wie "runasadmin"...

Bei Jürgen Lüthje habe ich nun entsprechende Freeware gefunden: RunAsAdmin 1.01

Damit wäre dann auch das Problem zu lösen, das ich immer mal mit externen NTFS-Datenträgern habe, dass ich den Verzeichnissen darauf erst mal Schreibberechtigung für die Gruppe "Benutzer" zuweisen muss, damit sie an mehreren PCs zum Datenaustausch verwendbar sind:

@ECHO OFF
REM ohne Parameter aufgerufen
IF "%1" == "" GOTO syntax
REM Versuch, das Wurzelverzeichnis zu übergeben
IF "%~p1" == "\\" GOTO syntax
RunAsAdmin icacls "%1\*" /grant Benutzer:M /T
GOTO :end
:syntax
ECHO Erteilt Schreibberechtigung für ein Verzeichnis und alle enthaltenen Dateien und Unterverzeichnisse
ECHO WARNUNG: *NICHT* auf das Wurzelverzeichnis (X:\) anwenden!
ECHO Syntax: %~n0 ^<Lw:\Pfad^>
:end

Falls so etwas doch noch mit Bordmitteln möglich ist, würde ich mich über Hinweise freuen. Kleiner Nachteil ist natürlich, dass sich für den mit erhöhten Rechten aufgerufenen Befehl ein neues Interpreterfenster öffnet und danach verschwindet; wer am Ende warten will, muss vielleicht doch mit zusätzlicher Batch inkl. PAUSE oder mit "cmd /k" arbeiten.

Mal ein großes Lob an den Microsoft-Support für Security Essentials: Auf einem Firmenrechner mit Windows 7 und per EasyTransfer übernommenem ehemaligem XP-Nutzerkonto wollte sich MSSE nicht mehr installieren lassen, obwohl zuvor es schon mal lief. Email-Support-Ticket erstellt, Fernwartungs-Termin abgesprochen, per Telefon und LogMeIn die Registry gereinigt ... läuft.  :thumb1: 

Sicherlich wäre es wohl etwas hilfreicher gewesen, wenn der Installer ausführlich hätte protokollieren können, warum er die Installation verweigert; wer nur Fehlercodes hat, der muss auch als MS-Mitarbeiter teilweise Foren weltweit durchsuchen und alle eventuell relevanten Teile zusammentragen (bis hin zu Hexadezimal-Registryschlüsseln).

Ursache war in diesem Fall wohl, dass durch EasyTransfer aus dem Windows-XP-Konto ein paar Registry-Schlüssel übernommen wurden, die der Installer von Security Essentials so nur unter Windows XP erwartet, aber nicht unter Windows 7 (HKCR\Installer\UpgradeCodes), wie auch in Uninstalling Microsoft Security Essentials in der "MSREMOVAL"-Batch enthalten.

(auch im TechNet geschrieben)

Bis zu Windows XP war ich es gewohnt, in vielen Programmen in einem Dateidialog mit Explorer-Control, v.a. verschiedene Varianten von "Datei speichern (unter)" je nach Common/Shell-Controls-Generation, auf eine Datei mit einem möglichst ähnlichen Namen zu klicken (nehmen wir mal "Dokument-Vorlage.doc" nur als Beispiel), dann den Namen in der darunter befindlichen Eingabezeile ein wenig abzuändern (z.B. in "Dokument-Variante.doc"), und dann das aktuelle Dokument unter diesem neuen Namen zu speichern.

Seit Windows 7 geht das nun nicht mehr so einfach mit vielen Programmen. Ein Klick auf eine Datei in einer Verzeichnisinhalt-Anzeige scheint dort noch etwas mehr zu tun, wodurch nun der im Verzeichnisinhalt markierte Dateiname teilweise über dem in der Eingabezeile bearbeiteten Dateinamen bevorzugt wird.

Zusammengefasst:

1. "Dokument-Vorlage.doc" angeklickt
2. Dateiname-Feld in "Dokument-Variante.doc" geändert
3. Programm fragt: "Datei Dokument-Vorlage.doc überschreiben?"

Mein bisheriger Workaround: Ins übergeordnete Verzeichnis wechseln und wieder in das vorherige Verzeichnis zurückkehren, damit im Verzeichnisinhalt garantiert keine Datei mehr markiert ist und der bearbeitete Dateiname akzeptiert wird.

Geht das auch weniger umständlich?

"Neben sämtliche Dateinamen klicken" oder F5 zum Auffrischen des Inhaltes helfen nicht; wenn einmal eine Datei in der Verzeichnisanzeige markiert wurde, dann ist immer mindestens eine Datei markiert, außer man kommt frisch in dieses Verzeichnis gewechselt.