derTippfehler

Ok, wir habens nun hinbekommen. Sollte also mal jmd auf gleiche / ähnliche Problematik stoßen so wäre zu überprüfen, ob das gleiche Share unter anderen Ebenen mehrfach gemountet ist. Beispiel: Laufwerk T:\ als \\servershareA\daten Laufwerk S:\ als \\servershareA\daten\Abteilung Das scheint der Adobe Acrobat so ganz und gar nicht zu mögen, kann sich dann wohl nicht für einen Laufwerksbuchstaben entscheiden - wenn man die PDF-Dateien per UNC-Pfad ansteuert zum umkonvertieren ist die Funktion _immer_ gegeben, ebenso per FQDN. Vielleicht hilfts ja mal jemanden. :-) Trotzdem ein "Danke!" an alle, die sich mit Vorschlägen beteiligt haben!!! thx & greetz

Aber das Umbiegen der Eigenen Dateien auf D:\Data geschieht bei allen Kennungen auf allen Maschinen... und wenn 2 Kennungen _kein_ lokales Profil auf einer Maschine haben, sich also beide zum ersten Mal anmelden und bei A ist dei Funktion gegeben, bei B aber nicht... *grübel*

Vielleicht um es noch mal zu verdeutlichen: Das Problem ist rein kennungsbezogen und nicht abhängig von lokal liegenden Userprofilen. Verändert wird am Userprofil AD-seitig natürlich die Gruppenmitgliedschaft - die Userkennung ist Mitglied der Gruppe, die Vollzugriff auf das besagte Share hat in dem die PDF-Dateien liegen, die per Adobe Acrobat zusammen geführt werden sollen. Sorry übrigens, wenn ich nicht alle Rückfragen so beantworte wie Ihr es in der AD-Abteilung sonst vielleicht gewohnt seid - ich bin _eigentlich_ Backoffice-Client-Support und bin daher nicht so ganz extrem tief in der Materie zu AD-Objekten und dem technischen Hintergrund zu object-copy / flags etc. :-) greetz

So, kurze Rückmeldung: Adobe Acrobat wurde nun bis einschl. 9.4.5 hochgepatcht, unter besagter Userkennung ist weiterhin der Fehler gegeben. Wirklich ärgerlich, scheinbar werden wir um eine neue Userkennung somit nicht herum kommen - vorher werde ich jedoch mein Glück nochmal mit procmon versuchen, ob irgendwelche Fehler / Probleme bei Zugriffen ersichtlich sind. :-( thx & greetz

Danke für diese Idee - jedoch wirkt besagte Ordnerumleitung (bleibt lokal, auf D:\Data ) auf alle verprobten Accounts an allen Clients und kann somit auch nicht als Verursacher herangezogen werden. Dennoch werde ich hier mal einen Crosstest starten um sicherzugehen. :-) Zum Export der AD-Objekte zu Vergleichszwecken per LDIFDE habe ich die Zwischenmeldung erhalten, dass keine Unterschiede ersichtlich waren - aber daran wird wohl noch gebastelt.

Nein, es gibt keine servergespeicherten Profile. Adobe Acrobat 7 behauptet als Fehler "Pfad nicht gefunden" (Pfade sind aber ordnungsgemäß eingebunden und per Ping ohne Unterbrechung erreichbar), Adobe Acrobat 9 sagt nur lapidar "Fehler". Gerne würde ich ja auch die Anwendung als Fehlerquelle hernehmen - diese funktioniert aber an 2 Clients in gleichen Pfaden & mit gleichen Dateien aber fehlerfrei sobald ein anderer Acc genutzt wird. :-/

Doch, macht es - das Zusammenführen von PDF-Dateien per PDFCreator funktioniert. Das Problem, dass PDFDateien nicht per Adobe Acrobat zusammen geführt werden können wird auf jeden Rechner "mitgenommen" auch wenn nie zuvor eine Anmeldung statt fand - ein Problem des lokalen Userprofils am Client scheidet somit aus. Auch, dass der kopierte User das gleiche Problem aufweist (ebenfalls Clientübergreifend) deutet ja auf ein problem des AD-Objektes "User" hin, oder? In ADSI Edit haben wir in den Eigenschaften des kopierten / des neuen Users mit gleichen Gruppen keine relevanten Unterschiede finden können. Exportieren und abgleichen werden wir Sie heute mal wenn Zeit ist - für weitere Vorschläge und Gedankengänge bin ich aber offen. :-) thx & greetz

Hallo, entschuldige bitte, ich hatte die geringe Hoffnung, dass die Anfrage im eigentlichen Sinne ausreicht und der Fehler nicht detailliert dargelegt werden muss um auf diese Antwort zu erhalten. :-/ Zu Sache: Ein Anwender hat Probleme mit der Software Adobe Acrobat PDF-Dateien, die in Netzwerkshares liegen zusammenzufügen - mit den gleichen Dateien lokal liegend oder in seinem Homeshare (auf anderem Server) besteht kein Problem damit. Es wurden diverse Crosstests gemacht und als "Verursacher" des Problems wurde die Kennung des Anwenders ermittelt. Ab diesem Punkt sind wir dann bei obiger Anfrage - wenn ich das Userkonto kopiere so kopiere ich das Problem mit und es bleibt bestehen, selbst wenn ich alle Gruppenzugehörigkeiten entferne. Lege ich ein neues Konto an und weise die _gleichen_ Gruppen zu so besteht kein Problem. Ich suche also quasi nach dem kleinsten gemeinsamen Nenner, der für die Problemstellung in Frage kommt. :-) greetz

Hi allz, ich raufe mir gerade die letzten verbliebenen Haare aufgrund folgenden Fehlers: Aufgrund von Applikations-spezifischen Zugriffsproblemen, die nachweislich & durch ausführliche Crosstests am Useraccount liegen wurde dieser testweise kopiert und nimmt den Fehler dann prompt mit - allerdings auch dann, wenn anschließend alle Gruppenmitgliedschaften händisch entfernen werden. Das eigentliche Problem muss also am Grundobjekt verankert sein und wird mitkopiert - wenn ein NEUER User angelegt wird und diesem die _gleichen_ Gruppen zugewiesen werden so ist das Problem nicht existent. Aufgrund von komplexen Strukturen & SID-Abhängigkeiten ist das kopieren / neu anlegen allerdings eher weniger gewünscht, wir suchen eigentlich aktuell nach dem eigentlichen Verursacher-Bit... Irgendjemand einen heißen Tipp für mich, welche Parameter beim kopieren unangetastet bleiben, beim neuen Objekt "anders" sind und bei Zugriffsprobleme Verursacher sein können? thx & greetz