Hallo,

wir haben folgendes Problem festgestellt. Wenn wir eine Software (MSI) im angemeldeten Zustand installieren, kommt es bei einigen Paketen vor, dass der o.g. Fehler auftritt.
Z.B. Java 6 Update 30

Die Werte in der Registry im Default-User (User Shell Folders) sind auch alle auf %USERPROFILE% gesetzt, was auch nach C:\Dokumente... verweist.
Die Werte des angemeldeten Users haben teilweise x:\system\etc.

Seltsamerweise funktioniert die Verteilung aber, wenn ich in einer cmd-Box DXDist.exe aufrufe. Hier bekomme ich keinen Fehler und die Installation läuft sauber durch.
Nach langem Testen scheint dafür der Registry-Eintrag des angemeldeten Users: HKCU\Software\Microsoft\Windows\Current Version\Explorer\User Shell Folders\AppData verantworlich zu sein.
Hier steht beim angemeldeten User x:\ drin. wenn ich das nach %USERPROFILE% ändere, dann läuft die Installation durch.

Erkennbar ist, dass die SW-Installation unter dem lokalen dxadm läuft, die User Shell Folders Einträge vom Benutzer nimmt und dann x: als dxadm natürlich nicht finden kann.
Wie es zu lösen ist, weiß ich allerdings nicht, da die Pfade erhalten bleiben müssen. Im Paket vorher x: nach c: zu substituieren halte ich auch nicht für sinnvoll

Freundliche Grüße
Tobias Zielke

Das Problem hatte ich auch des öfteren. Eine Lösung habe ich dafür leider nicht, die einzige Möglichkeit war die Umleitung der Ordner auf Netzlaufwerke auszuschalten bzw. den Regkey Eintrag manuell für die Zeit der Installation zu ändern.

Ob es eine Lösung gibt, ist sowieso fraglich, da wie schon erwähnt die Installation mit dem lokalen Admin (dxadm) durchgeführt wird und generell der lokale Benutzer kein Zugriff auf die Netzlaufwerk hat.
Eventuell muss man in den MSI Properties was ändern, habe aber noch nichts herausgefunden.

Dazu: http://www.softservice.de/de/support/kno...63e399ad56baf7f


Vielleicht könnte das hier die Lösung sein: http://www.microsoft-questions.com/micro...ders-check.aspx

I had a similar problem years ago with some users who I believe were set up
for roaming profiles, or "my documents" was stored on a server somewhere (I
forget the exact details). But I tracked down the problem to be the fact
that Windows Installer was trying to make sure that every directory that I
have in the directory table is accessable. For those users who were offline
or the server was unavailable, they would get an error 1327. Since my setup
wasn't installing anything into their "my documents" folder, the fix was
easy -- just remove that and any other "my" folders, such as music,
pictures, etc., from my directory table.

When you modified your MSI to install shortcuts to the non-redirected paths
(%USERPROFILE%), did you delete the desktop directory table entry? I think
you will find it will work for you once you delete any unused directory
table entry which is redirected to a network server. And hopefully placing
the shortcuts in that userprofile folder is a viable solution for you, and
not just a test that you were trying.

hat das was geholfen?

Ich habe es derzeit mit einem subst gelöst und werde es bis zum 7.0.4 Client beibehalten;)

Vielen Dank.