nikolausdulgeridis
  Die gekaperte Excel Datei
 
Excel Datei durch Benutzer gesperrt
Troubleshooting Guide

Generationen von Support Mitarbeitern kennen das Phänomen: die Excel Datei ist zur Bearbeitung durch einen anderen Mitarbeiter gesperrt. Eine Übersicht zu Ursachen, Behebung und noch wichtiger Vermeidungsstrategien.

Warum: 

Excel stammt aus einer Zeit, in der die Menschen über die Computer noch herrschten. Verzicht und Teilen war den Individuen jener Epoche unbekannt. Eigentlich sympathisch, aber Dateien werden grundsätzlich exklusiv zum Bearbeiten geöffnet, auch wenn der Benutzer nur etwas nachschlagen will. Das führt in Netzwerkumgebungen mit vielen Nutzern zwangsläufig zu Konflikten.

Abhilfe:
 
Nicht der Nutzer, der die Datei bearbeiten will verursucht die Sperre, sondern der Mitarbeiter der die Datei zuletzt bearbeitet bzw. geöffnet hat. Dieser muss das Dokument schliessen.

 
Abhilfe allgemein:
 
Es wird üblicherweise empfohlen, dass der sperrende Mitarbeiter sich einmal vom Netz abmeldet. Es ist wichtig, dass das genau auf dem PC geschieht, auf dem die Excel Datei geöffnet war oder ist. Eine andere Möglichkeit besteht darin, 24 Stunden zu warten, bis die Sperre aufgehoben wird. Der Support leistet nur in dringenden Fällen Unterstützung, da das Thema in der Userverantwortung liegt. In den meisten wird das Problem verursacht, wenn dee Mitarbeiter den Laptop zuklappt und in den Feierabend geht.

Man kann auch versuchen, mit compmgmt.msc alle geöffneten Dateien zu trennen.

Zuweilen erhält ein Anwender die Meldung, dass die Datei durch ihn selbst gesperrt ist. Das ist verwunderlich, sitzt doch der Betreffende gerade selbst vor dem Computer. Um das zu verstehen, muss man sich darüber klar werden, dass Excel mehrfach geöffnett werden kann, sogar auf verschiedenen Computern. Man muss also genau den PC finden, auf dem die sperrende Instanz läuft und diesen durchstarten, bzw. sich davon abmelden.

[Man kann auch auf dem Fileserver die Sperre lösen. Bei Linux lässt sich mit Lsof der sperrende Samba Prozess identifizieren, bei Windows ist die Vorgehensweise analog. Das sei aber nur am Rande erwähnt. In Firmennetzen ist die Bereitschaft des Supports, bei diesem Problem zu unterstützen begrenzt. Es ist nicht nur u.U. eine Kostenfrage den Fachsupport zu involvieren, es ist vor allem auch unerwünscht auf einem produktiven Server Prozesse abzuschiessen.]
  
Vermeidung:
Natürlich ist es kein Verbrechen, den Laptop zuzuklappen, dafür sind die Geräte konstruiert. Je mehr Personen auf eine Datei Zugriff haben, um so wahrscheinlicher kommt es zu Unfällen. Schön wäre es, wenn das Problem gar nicht erst entsteht. Die Möglichkeiten sind:
 
a. Wahl des Dateityps - simpel
b. Tabelle für die gemeinsame Bearbeitung freigeben 
c. Publizieren einer Kopie im Intranet (z. Bsp. als Html oder Pdf)
d. Tabelle Readonly setzen 
e. Excel Tabelle per Verknüpfung Readonly aufrufen
 
zu a) Wahl des Dateityps
Veröffentlicht man eine Tabelle als .xlsm (bei Word empfiehlt sich .doc), dann wird die Tabelle bei 99 Prozent der Benutzer erst nach mehrfachem Klicken für die Bearbeitung freiigegeben. Allerdings ist der Dateityp etwas anstregend. Manche Emailfilter schlagen bei Erkennung dieses Dateityps Daueralarm und manche Systempolicies sind so scharf geschaltet, dass der Benutzer auch nicht glücklich wird. Man kann auch mit älteren Dateiformaten (Win98) experimentieren, auch hier wird vor dem Bearbeiten meist Klickalarm ausgelöst und sie kommen im Gegensatz zu .xlsm problemlos durch die Virenfilter.
 
zu  b) Tabelle für die gemeinsame Bearbeitung freigeben 
Das ist vermutlich die simpelste Umgehung des Problems, da eine gemeinsame Tabelle nicht durch einen anderen Bearbeiter gesperrt.werden kann. Trotzdem nur eine Teillösung, weil jeder Benutzer unbeabsichtigte Änderungen vornehmen kann und das ist eine unerwünschte Fehlerquelle.
 
zu c) Publizieren einer Kopie im Intranet z. Bsp. als Pdf oder Html
Diese Methode ist ein wenig aufwendig, weil man bei jeder Aktualisierung auch die Kopie auf dem laufenden Stand halten muss. In manchen Fällen ist es trotzdem die beste Wahl, man kann z. Bsp.einen Dienstplan sowohl im Intranet publizieren, als auch an die Mitarbeiter versenden. Evtl. stellt man auch das Excel Dokument selber ins Intranet, der Browser Plugin fungiert dann als Reader. 

zu d) Tabelle Readonly setzen
Hier gibt es 2 Möglichkeiten: einmal in Excel oder im Dateisystem. 
Beide Möglichkeiten überzeugen wenig. Um es kurz zu machen: Das setzen der Option in Excel ist fürchterlich aufwendig, weil man vor jeder Bearbeitung erst wieder entsperren und nachher wieder sperren muss (genau hier hat Microsoft eine Möglichkeit verpasst das Thema anzugehen). Das Setzen des Readonly Attributs im Dateiexplorer ist auch keine glückliche Lösung. Beide Methoden eignen sich vor allem für Dokumente, die ein finales Stadium erreicht haben.

Dritte Variante: im Netz: Oft lohnt es sich, die Bearbeitung über die Netzwerkberechtigung zu regeln, aber das ist ein anderes Thema.(Um die Fragestellung abzugrenzen: es geht hier nicht um Sicherheitsfragen. Menschen fahren in Urlaub, trotzdem sollen die Kollegen in der Lage sein, eine Vertretung zu organisieren oder einen Fehler im Wiki zu korrigieren. Anders gesagt, es sollen keine Berechtigungen vergeben, sondern die kollisionsfreie Zusammenarbeit erleichtert werden). Gelegentlich sieht man in Firmennetzen, dass die selbe Datei in zwei verschiedenen Pfaden angeboten wird, einmal zum Lesen einmal zum Bearbeiten. Das gefällt mir aus bestimmten Gründen nicht, aber es löst das Problem.

zu e) Excel Tabelle per Verknüpfung Readonly aufrufen 
Das sieht auf den ersten Blick nach der perfekten Lösung aus. Das Problem ist ja, dass Excel jedes Dokument per default exklusiv zum Bearbeiten öffnet. Dadurch kann unbeabsichtiigt die Tabelle gesperrt oder versehentlich verändert werden. Man kann allerdings Excel bereits beim Aufruf mitteilen, dass nur Lesezugriff benötigt wird und zwar mit der Oprion /r. Klingt einfach, ist es aber nicht, sonst würde es jeder machen. Und zwar wegen der technischen Details.
Punkt 1: Wir benötigen den Pfad zu Excel. Und der kann unterschiedlich sein, je nach Office Version. Ein typischer Pfad ist. C:\Program Files (x86)\Microsoft Office\Office14\. (In der Rregel läuft Excel direkt auf dem PC des Nutzers, bei einer Citrix Verbindung kann es sich aber natürlich um einen ganz anderen Rechner handeln. Das bedeutet, selbst wenn ich den Pfad habe, kann ich den Link nicht einfach an Kollegen verteilen, sofern ich nicht weiß welche Excel Version auf dem Computer des Empfängers installiert ist. Das sollte aber kein Problem sein, da die Kollegen voraussichtlich einen Firmenrechner nutzen. Bei Citrix ist die Lage noch einfacher, da alle auf dem selben PC arbeiten).
Man könnte in Betracht ziehen ein Programm zu schreiben, das den Excel Pfad beim Aufruf dynamisch ermittelt. Aber: eine Exe zum Auslesen des Systempfads im Firmennetz verteilen? Womöglich per Email? Das ist die Hölle! Haben die Nutzer Adminrechte? Das vergessen wir am besten gleich wieder.
Punkt 2: den Dokumentpfad hinzufügen (mit vorangestelltem /r natürlich). 
Der fertige Link sieht dann etwa so aus (Anführungsstriche nicht vergessen):
"C:\Program Files (x86)\Microsoft Office\Office14\" /r "meinpfad\meindokument.xls"
Damit können wir eine Verknüpfung basteln oder eine batch Datei. (Leider klappt es nicht, den Link in eine Mail, Word-Dokument, PDF oder Html einzubauen und zwar wegen der Sicherheitsbeschränkungen (nicht Policies, diese sind ausnahmsweise nicht gemeint), einzige Ausnahme: .hta Dateien. Ob die Sicherheitseinschränkungen sinnvoll sind, sei dahingestellt, es ist halt so).  
Punkt 3: verteilen Die Verknüpfung müssen wir im Anschluss noch verteilen, das ist ja Sinn der Sache.. Leider passen i.d.R. weder Verknüpfung noch Batch Datei durch den Email Filter (manchmal hat man aber Glück und die gezippte Version geht durch). Stattdessen stellen wir die Verknüpfung auf ein Share Laufwerk im Netz und verteilen einen Link auf diese Verknüfung.. Voila, Problem gelöst.
Kurze Zusammenfassung: Wir erstellen eine Readonly-Verknüfung und speichern diese im selben Pfad wie die Excel Tabelle. Die Kollegen erhalten nun zwei Links, einen auf das Dokument (zum Schreiben) und einen auf die Verknüpfung (nur lesen). 

Um die Problematik mit dieser Variante noch einmal verständlich zu machen. Die normale Schnittstelle sieht vor, der User klickt auf die Datei und der Computer (bzw. das OS) wählt automatisch die passende Anwendung, in diesem Fall Excel. Wir ahnen jedoch voraus, dass Excel benötigt wird und geben in der Verknüfung an "Excel.exe /r Datei", um Excel zu überreden, die Datei nicht!! exklusiv zu öffnen. Nun gibt es zahlreiche Sicherheitsbeschränkungen die Krimininellen das Leben schwer machen sollen. Auf unserem eigenen Computer hätten wir keine Probleme eine praktikable Lösung zu finden, da wir die Datei bzw. den Link darauf aber im Netz verteilen wollen, haben wir mit verschiedensten Hürden zu kämpfen. Die Ursache der Thematik liegt natürlich letztlich in dem Umstand, dass 'moderne' Sicherheitskonzepte über alte Strukturen gestülpt wurden. Ob hier mit dem Schrotgewehr geschossen wurde oder ob die alten Strukturen nicht mehr den Anforderungen genügen, kann nicht eindeutig beantwortet werden, ein wenig trifft beides zu. Allerdings fehlt hier der Platz um darauf einzugehen.

Hinweise:
 
Desktopverknüpfung erzeugen::
 "<Pfad zu Excel.Exe>" /r "<Pfad zum Dokument>"
  
Übersicht Excel commandline Parameter
  https://support.microsoft.com/de-de/help/291288/description-of-the-startup-switches-for-excel
 
Registry-Schlüssel zur Ermittlung des Pfads zu Excel.exe
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\9.0\Excel\InstallRoot (Veraltet)
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe
    C:\Program Files (x86)\Microsoft Office\Office14\
 
Application Path per Excel Makro abfragen:
    MsgBox Application.Path

----------------------
Seite erstellt: 4.9.2019
geaendert: 27.12.2019
 
  4 Besucher