Hallo zusammen,
ich hbae folgendes Problem, ich möchte per Client Command einen Link auf eine *.doc Datei erstellen, die bei uns auf einem Netzlaufwerk liegt.
Dieses sollte ja kein Problem sein, denn mit dem Command 'Create Shortcut' ist das ja einfach zu realisieren. Dabei tritt jedoch folgendes Porblem auf, nach erfolgreichem Ablauf des Scripts ist der Shortcut an entsprechender Stelle auch vorhanden, jedoch ist der Pfad zur Zieldatei "verkrüppelt" alles was zwischen den einzelnen '\' steht wurde auf acht Zeichen zusammen gestrichen.
Um es bildlicher auszudrücken:
Es soll folgender Link erzeugt werden z:\Testlaufwerk\test verzeichnis\Beispiel ordner\Zieldokument.doc
Daraus erzeugt das ACMP Skript dann z:\Testlauf\test ve\Beispiel\Zieldoku
Dabei ist es vollkommen egal ob ich das mit oder ohne " schreibe.
Ich habe es dann anders versucht und mit Hilfe des Tools 'machlink.exe' getestet und ein Batch Script in dem ACMP Script erstellt => selber Fehler
Dann habe ich eine separate *.bat Datei geschrieben und diese dann auf den Zielrechner kopiert und per 'Execute Commadn' ausgeführt => selber Fehler
An dem Batch Script kann es nicht liegen das funktioniert manuell auf dem PC ausgeführt ohne Probleme und erzeugt auch den korrekten Link.
Ist das ein generelles Problem ??
Ich bin so langsam am Ende meines Lateins
In der Hoffnung auf Hilfe,
Lothar
Links zu Datei werden verküppelt erstellt
-
Lothar.Struth
- Beiträge: 18
- Registriert: Fr Apr 30, 2010 11:51 am
Universität Witten/Herdecke
-
thellweg
Hallo Herr Struth,
das ist ein bekannter Effekt welcher schon häufiger, auch in unseren ClientCommands, auffiel wenn man versuchte Links auf Netzlaufwerke, also mit einem Laufwerksbuchstaben, mit einem CC zu erzeugen.
Adressieren Sie den Pfad einmal als UNC Pfad, dann sollten die Verzeichnisnamen nicht mehr auf acht Zeichen zusammengestrichen werden.
Die genaue Erklärung warum dies so ist bekomme ich aus dem Gedächtnis leider nicht mehr vollständig zusammen.
Bevor ich nun aber einen Unsinn schreibe, belasse ich es lieber bei dem Hinweis auf die Lösung!
das ist ein bekannter Effekt welcher schon häufiger, auch in unseren ClientCommands, auffiel wenn man versuchte Links auf Netzlaufwerke, also mit einem Laufwerksbuchstaben, mit einem CC zu erzeugen.
Adressieren Sie den Pfad einmal als UNC Pfad, dann sollten die Verzeichnisnamen nicht mehr auf acht Zeichen zusammengestrichen werden.
Die genaue Erklärung warum dies so ist bekomme ich aus dem Gedächtnis leider nicht mehr vollständig zusammen.
Bevor ich nun aber einen Unsinn schreibe, belasse ich es lieber bei dem Hinweis auf die Lösung!
Kurz zur Erklärung:
Es handelt sich um einen Windows Bug!
Der Lokale System Dienst darf in dem Moment nicht auf die Freigabe, somit ist das Verzeichnis nicht vorhanden und somit wird gekürzt!
Nachzulesen unter
http://support.microsoft.com/?scid=kb%3 ... 4&x=8&y=11
Es handelt sich um einen Windows Bug!
Der Lokale System Dienst darf in dem Moment nicht auf die Freigabe, somit ist das Verzeichnis nicht vorhanden und somit wird gekürzt!
Nachzulesen unter
http://support.microsoft.com/?scid=kb%3 ... 4&x=8&y=11
Mit freundlichen Grüßen,
H. Schriek
H. Schriek
-
Lothar.Struth
- Beiträge: 18
- Registriert: Fr Apr 30, 2010 11:51 am
Hallo herr Schriek,
das würde aber bedeuten, würde ich das Batch File mit einem anderen User ausführen, der die Rechte zum Zugriff auf diesen Pfad hat, würde, müsste das Ganze ohne Probleme funktionieren, doder ??
Vielen Dank schon einmal für den Tip.
Gruß,
Lothar
das würde aber bedeuten, würde ich das Batch File mit einem anderen User ausführen, der die Rechte zum Zugriff auf diesen Pfad hat, würde, müsste das Ganze ohne Probleme funktionieren, doder ??
Vielen Dank schon einmal für den Tip.
Gruß,
Lothar
Universität Witten/Herdecke
-
Lothar.Struth
- Beiträge: 18
- Registriert: Fr Apr 30, 2010 11:51 am
Hallo Herr Schriek,
hab das mit "Ausführen als.." getestet, leider ohne Erfolg.
Ich denke dann werden wir es mit dem UNC Pfad versuchen.
Nochmal Vielen Dank ann Alle.
Gruß,
Lothar
hab das mit "Ausführen als.." getestet, leider ohne Erfolg.
Ich denke dann werden wir es mit dem UNC Pfad versuchen.
Nochmal Vielen Dank ann Alle.
Gruß,
Lothar
Universität Witten/Herdecke
-
Lothar.Struth
- Beiträge: 18
- Registriert: Fr Apr 30, 2010 11:51 am
Hallo zusammen,
habe mir nun eine Lösung erbastelt.
Wenn man vor dem erstellen der Verknüpfung ein 'Execute Command' mit "%WINSYSDIR%subst.exe" und den Parametern "x: c:\" aufruft, wobei das 'x' das Netzlaufwerk ist.
Dann die Verknüpfung normal erstellt und anschließend wieder mit einem 'Execute Command' mit "%WINSYSDIR%subst.exe" und den Parametern "x: /d" aufruft, wobei das 'x' das Netzlaufwerk ist.
Dann wird die Verknüpfung auch korrekt erstellt. Dies ist eigentlich nur dem Microsoft Artikel entnommen, nur das ich das Ganze nicht mit einem VB-Script mache sondern halt mit einem Client Command.
Vielleicht hilft das ja dem einen oder anderen hier.
Gruß,
Lothar
habe mir nun eine Lösung erbastelt.
Wenn man vor dem erstellen der Verknüpfung ein 'Execute Command' mit "%WINSYSDIR%subst.exe" und den Parametern "x: c:\" aufruft, wobei das 'x' das Netzlaufwerk ist.
Dann die Verknüpfung normal erstellt und anschließend wieder mit einem 'Execute Command' mit "%WINSYSDIR%subst.exe" und den Parametern "x: /d" aufruft, wobei das 'x' das Netzlaufwerk ist.
Dann wird die Verknüpfung auch korrekt erstellt. Dies ist eigentlich nur dem Microsoft Artikel entnommen, nur das ich das Ganze nicht mit einem VB-Script mache sondern halt mit einem Client Command.
Vielleicht hilft das ja dem einen oder anderen hier.
Gruß,
Lothar
Universität Witten/Herdecke
-
thellweg
Lieber Herr Struth,
diese "alte Geschichte" hat mir keine Ruhe gelassen und ich habe mich deshalb auch noch ein wenig im Erstellen von Verknüpfungen geübt.
Hier meine Ergebnisse:
Der Benutzerkontext mit dem der Link erzeugt wird ist nebensächlich. Es wird immer nach dem 8en Zeichen gekappt, solange es sich um ein Netzlaufwerk handelt.
Grund dafür ist der in dem MS-KB Artikel geschilderte Windows-Bug. Witzig ist aber folgendes:
Der Versuch die Unterstützung von langen Dateinamen zu prüfen wird scheinbar nur für das Verknüpfungsziel durchgeführt, wo er scheitert.
Ein durch "Ausführen in" angegebener Zielordner wird dagegen ebenso sauber mit seinem langen Namen aufgelöst wie ein Pfad zu einem Icon!
Wird der Shortcut-Pfad als UNC Pfad angegeben erfolgt diese Prüfung offensichtlich nicht und der Shortcut wird sauber angelegt.
Aus Benutzersicht ist es lediglich erforderlich mit dem Kontext des am Computer angemeldeten Benutzers Zugriffsrechte für das Ziel des Shortcuts zu besitzen.
Anmerkung: Das CC, mit welchem ich den Shortcut gesetzt habe, konnte stets nur mit "run as service" einen Shortcut erzeugen.
Dabei sorgt ein scheinbarer Fehler im Client-Log "cannot force Work directory" für ein stoppen (roter Balken im CommandLauncher) des CCs.
Da das CC aber dennoch den Shortcut ordentlich erzeugt, kann man diese Meldung ignorieren. Ich habe den Haken für "ignore error" gesetzt.
Ich hoffe Hr. Schriek und ich konnten Ihr Problem zufriedenstellend lösen.
Nachtrag bezüglich des Subst-Tricks.
Funktioniert das denn wirklich so?
Wenn man einen Shortcut zu dem Pfad "z:\Testlaufwerk\test verzeichnis\Beispiel ordner\Zieldokument.doc" erstellen möchte und vor dem Erstellen des Shortcuts den Laufwerksbuchstaben Z:\ zu C:\ substituiert, dann müsste die im Pfad angegebene Zieldatei unter einer identischen Ordnerstruktur doch auch auf C:\ vorhanden sein um einen gültigen Shortcut zu erzeugen. Ansonsten bekäme man doch eine Fehlermeldung "Zielpfad nicht gefunden" oder befinde ich mich da jetzt im Irrtum?
diese "alte Geschichte" hat mir keine Ruhe gelassen und ich habe mich deshalb auch noch ein wenig im Erstellen von Verknüpfungen geübt.
Hier meine Ergebnisse:
Der Benutzerkontext mit dem der Link erzeugt wird ist nebensächlich. Es wird immer nach dem 8en Zeichen gekappt, solange es sich um ein Netzlaufwerk handelt.
Grund dafür ist der in dem MS-KB Artikel geschilderte Windows-Bug. Witzig ist aber folgendes:
Der Versuch die Unterstützung von langen Dateinamen zu prüfen wird scheinbar nur für das Verknüpfungsziel durchgeführt, wo er scheitert.
Ein durch "Ausführen in" angegebener Zielordner wird dagegen ebenso sauber mit seinem langen Namen aufgelöst wie ein Pfad zu einem Icon!
Wird der Shortcut-Pfad als UNC Pfad angegeben erfolgt diese Prüfung offensichtlich nicht und der Shortcut wird sauber angelegt.
Aus Benutzersicht ist es lediglich erforderlich mit dem Kontext des am Computer angemeldeten Benutzers Zugriffsrechte für das Ziel des Shortcuts zu besitzen.
Anmerkung: Das CC, mit welchem ich den Shortcut gesetzt habe, konnte stets nur mit "run as service" einen Shortcut erzeugen.
Dabei sorgt ein scheinbarer Fehler im Client-Log "cannot force Work directory" für ein stoppen (roter Balken im CommandLauncher) des CCs.
Da das CC aber dennoch den Shortcut ordentlich erzeugt, kann man diese Meldung ignorieren. Ich habe den Haken für "ignore error" gesetzt.
Ich hoffe Hr. Schriek und ich konnten Ihr Problem zufriedenstellend lösen.
Nachtrag bezüglich des Subst-Tricks.
Funktioniert das denn wirklich so?
Wenn man einen Shortcut zu dem Pfad "z:\Testlaufwerk\test verzeichnis\Beispiel ordner\Zieldokument.doc" erstellen möchte und vor dem Erstellen des Shortcuts den Laufwerksbuchstaben Z:\ zu C:\ substituiert, dann müsste die im Pfad angegebene Zieldatei unter einer identischen Ordnerstruktur doch auch auf C:\ vorhanden sein um einen gültigen Shortcut zu erzeugen. Ansonsten bekäme man doch eine Fehlermeldung "Zielpfad nicht gefunden" oder befinde ich mich da jetzt im Irrtum?
-
Lothar.Struth
- Beiträge: 18
- Registriert: Fr Apr 30, 2010 11:51 am
Hallo Herr Hellweg,
erstmal danke für die ausführliche Erklärung.
Das mit dem subst trick funktioniert tatsächlich, ich habe das so getestet. Wie ich jedoch gerade sehe legt er auf C:\ dann die Ordnerstruktur an, prüft jedoch nicht ob die Zieldatei darin vorhanden ist, ist auch etwas seltsam.
Naja, ich lösche dieses verzeiuchnis im Anschluß und habe dann meinen Link wie ich ihn brauche.
Was ich noch nicht verstanden habe, wie kann ich dieses "Run as service" einstellen ??
Ich habe schon gesucht es aber noch nicht gefunden, denn in dem "Create Shortcut" Optionen gibt es dazu nichts.
Gruß,
Lothar
erstmal danke für die ausführliche Erklärung.
Das mit dem subst trick funktioniert tatsächlich, ich habe das so getestet. Wie ich jedoch gerade sehe legt er auf C:\ dann die Ordnerstruktur an, prüft jedoch nicht ob die Zieldatei darin vorhanden ist, ist auch etwas seltsam.
Naja, ich lösche dieses verzeiuchnis im Anschluß und habe dann meinen Link wie ich ihn brauche.
Was ich noch nicht verstanden habe, wie kann ich dieses "Run as service" einstellen ??
Ich habe schon gesucht es aber noch nicht gefunden, denn in dem "Create Shortcut" Optionen gibt es dazu nichts.
Gruß,
Lothar
Universität Witten/Herdecke
-
thellweg
Hallo Herr Struth,
ich habe mich vielleicht etwas zu kompliziert ausgedrückt und Sie damit etwas verwirrt.
Jedes CC hat doch unter dem Tabellenreiter "Allgemein" die Selectbox mit den Auswahlen "Als Dienst ausführen" oder "Als Benutzer ausführen". Aus Ihren vorherigen Texten weiss ich, dass Sie die natürlich kennen. Es ist mir nicht gelungen mit der Einstellung "Als Benutzer ausführen" den Link anzulegen, selbst dann nicht wenn ich als Ziel den Desktop des Users ausgewählt hatte, wo dieser definitiv die erforderlichen Berechtigungen zum Anlegen eines Shortcuts besitzt.
Naja, Dateien mit der Endung .LNK sind eben doch keine "normalen" Dateien und folgen in einigen Fällen, so wie diesen, eben auch ihren eigenen teilweise rätselhaften Gesetzen.
Anmerkung bezüglich des Subst-Tricks:
Schön das es prinzipiell funktioniert. Ich bin sicher das Sie bei dieser Variante auch keine Fehlermeldung bekommen, denn offensichtlich funktioniert das "force directory" auf dem lokalen Laufwerk. Deutlich daran erkennbar, dass bei Ihrem CC eine vorher nicht vorhandene Ordnerstruktur (eben der Pfad zur nicht vorhandenen Zieldatei) einfach so auf dem Laufwerk C:\ angelegt wird. Auf dem Netzlaufwerk gelingt dies dem ACMP Client-Service, aufgrund mangelnder Berechtigungen, natürlich nicht und daher kommt es bei meiner Lösungsvariante zur Ausgabe der erwähnten Fehlermeldung, welche ich mit dem Schalter "ignore error" unterdrücke. Warum hier überhaupt ein Versuch der Aktion "force directory" stattfindet ist zu diskutieren. Dies macht bei einem ohnehin vorhandenen Verzeichnispfad sicherlich kaum einen Sinn. Ich werde dies auf alle Fälle an unsere Entwickler weitergeben.
ich habe mich vielleicht etwas zu kompliziert ausgedrückt und Sie damit etwas verwirrt.
Jedes CC hat doch unter dem Tabellenreiter "Allgemein" die Selectbox mit den Auswahlen "Als Dienst ausführen" oder "Als Benutzer ausführen". Aus Ihren vorherigen Texten weiss ich, dass Sie die natürlich kennen. Es ist mir nicht gelungen mit der Einstellung "Als Benutzer ausführen" den Link anzulegen, selbst dann nicht wenn ich als Ziel den Desktop des Users ausgewählt hatte, wo dieser definitiv die erforderlichen Berechtigungen zum Anlegen eines Shortcuts besitzt.
Naja, Dateien mit der Endung .LNK sind eben doch keine "normalen" Dateien und folgen in einigen Fällen, so wie diesen, eben auch ihren eigenen teilweise rätselhaften Gesetzen.
Anmerkung bezüglich des Subst-Tricks:
Schön das es prinzipiell funktioniert. Ich bin sicher das Sie bei dieser Variante auch keine Fehlermeldung bekommen, denn offensichtlich funktioniert das "force directory" auf dem lokalen Laufwerk. Deutlich daran erkennbar, dass bei Ihrem CC eine vorher nicht vorhandene Ordnerstruktur (eben der Pfad zur nicht vorhandenen Zieldatei) einfach so auf dem Laufwerk C:\ angelegt wird. Auf dem Netzlaufwerk gelingt dies dem ACMP Client-Service, aufgrund mangelnder Berechtigungen, natürlich nicht und daher kommt es bei meiner Lösungsvariante zur Ausgabe der erwähnten Fehlermeldung, welche ich mit dem Schalter "ignore error" unterdrücke. Warum hier überhaupt ein Versuch der Aktion "force directory" stattfindet ist zu diskutieren. Dies macht bei einem ohnehin vorhandenen Verzeichnispfad sicherlich kaum einen Sinn. Ich werde dies auf alle Fälle an unsere Entwickler weitergeben.
-
thellweg
Hier noch ein kleiner "Behelfstrick", der es dem ACMP Clientservice ermöglichen kann auf eine Netzwerkressource zuzugreifen.
Dieses Thema wurde ja in diesem Thread angesprochen, daher passt der Hinweis auch gut hierher.
Noch einmal kurz die Problematik:
Prinzipiell hat der ACMP Clientservice, welcher auf einem beliebigen Computer ausgeführt wird, keine Berechtigungen um auf Netzwerkressourcen zuzugreifen, welche für den angemeldeten Benutzer, aufgrund Seiner Gruppenzugehörigkeiten, ohne Probleme erreichbar sind. In einem ClientCommand ist es jedoch manchmal erforderlich/nützlich auf Dateien einer Netzwerkressourrce zugreifen zu können. Im Idealfall können die entsprechenden Befehle dann im Kontext des Benutzers ausgeführt werden.
Dies wäre jedenfalls auch die "sauberste Lösung" dieses Problems!
Ein möglicher Lösungsansatz dazu:
Sollte diese "Impersonierung" einmal nicht möglich sein, kann man dem ACMP Clientservice, durch eine Modifikation der NTFS Rechte der betreffenden Netzwerkressource, den erforderlichen Zugriff verschaffen. Dazu ist es erforderlich die Gruppe der "Domänencomputer" in die ACL (access control list) der physikalischen NTFS-Ressource aufzunehmen und dort deren Zugriffsrechte auf die erforderliche Mindestberechtigung (oft genügt schon "lesen") einzustellen.
Achtung!
Eine Berechtigung der Gruppe der "Domänencomputer" sollte natürlich stets mit "Augenmaß" und nur in wirklich notwendigen Fällen vorgenommen werden, da es sich dabei um eine "Scheunentor-Lösung" handelt. Bitte beachten Sie daher unbedingt die, in Ihrem Unternehmen geltenden, IT-Sicherheitsrichtlinien und sprechen Sie sich ggf. vorher mit Ihrem IT-Sicherheitsbeauftragten ab. Wenn Sie die Berechtigungen auf das erforderliche Mindestmaß beschränken und es sich bei der Netzwerkressource nicht gerade um unternehmenskritische Daten handelt, ist die Anwendung dieses "Behelfstricks" durchaus legitim.
Selbstverständlich übernimmt die Aagon Consulting keine Haftung für möglicherweise, aus der unsachgemäßen Anwendung dieses Hinweises, entstehende Schäden ;o)
Dieses Thema wurde ja in diesem Thread angesprochen, daher passt der Hinweis auch gut hierher.
Noch einmal kurz die Problematik:
Prinzipiell hat der ACMP Clientservice, welcher auf einem beliebigen Computer ausgeführt wird, keine Berechtigungen um auf Netzwerkressourcen zuzugreifen, welche für den angemeldeten Benutzer, aufgrund Seiner Gruppenzugehörigkeiten, ohne Probleme erreichbar sind. In einem ClientCommand ist es jedoch manchmal erforderlich/nützlich auf Dateien einer Netzwerkressourrce zugreifen zu können. Im Idealfall können die entsprechenden Befehle dann im Kontext des Benutzers ausgeführt werden.
Dies wäre jedenfalls auch die "sauberste Lösung" dieses Problems!
Ein möglicher Lösungsansatz dazu:
Sollte diese "Impersonierung" einmal nicht möglich sein, kann man dem ACMP Clientservice, durch eine Modifikation der NTFS Rechte der betreffenden Netzwerkressource, den erforderlichen Zugriff verschaffen. Dazu ist es erforderlich die Gruppe der "Domänencomputer" in die ACL (access control list) der physikalischen NTFS-Ressource aufzunehmen und dort deren Zugriffsrechte auf die erforderliche Mindestberechtigung (oft genügt schon "lesen") einzustellen.
Achtung!
Eine Berechtigung der Gruppe der "Domänencomputer" sollte natürlich stets mit "Augenmaß" und nur in wirklich notwendigen Fällen vorgenommen werden, da es sich dabei um eine "Scheunentor-Lösung" handelt. Bitte beachten Sie daher unbedingt die, in Ihrem Unternehmen geltenden, IT-Sicherheitsrichtlinien und sprechen Sie sich ggf. vorher mit Ihrem IT-Sicherheitsbeauftragten ab. Wenn Sie die Berechtigungen auf das erforderliche Mindestmaß beschränken und es sich bei der Netzwerkressource nicht gerade um unternehmenskritische Daten handelt, ist die Anwendung dieses "Behelfstricks" durchaus legitim.
Selbstverständlich übernimmt die Aagon Consulting keine Haftung für möglicherweise, aus der unsachgemäßen Anwendung dieses Hinweises, entstehende Schäden ;o)