MSI repair source problem
[font="Microsoft Sans Serif"]
How is it typically handled when you install a fresh package via SMS - or an admin account, then when you log in as a Power User the app attempts to repair itself and begins to search for the source directory? I am fairly new to Wise Package Studio and I am having terrible problems with Adobe Acrobat 5.0.5 and the Groupwise 6 client.
The apps install and run just fine as admins, but when logging in with a power user account or user account, the apps attempt to repair themselves and the windows installer service attempts to seek the files off the source, like a network drive. It will obviously fail due to the install path not existing post intallation.
How is this handled? Any tips or suggestions are welcome.
TP
How is it typically handled when you install a fresh package via SMS - or an admin account, then when you log in as a Power User the app attempts to repair itself and begins to search for the source directory? I am fairly new to Wise Package Studio and I am having terrible problems with Adobe Acrobat 5.0.5 and the Groupwise 6 client.
The apps install and run just fine as admins, but when logging in with a power user account or user account, the apps attempt to repair themselves and the windows installer service attempts to seek the files off the source, like a network drive. It will obviously fail due to the install path not existing post intallation.
How is this handled? Any tips or suggestions are welcome.
TP
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
nmead
20 years ago
I used DFS with hidden Apps shares that are accessible to all users/computers. I then lockdown the filesystem to the groups that actually get the applications
DFS allows me to only have to use one path for all source paths in my packages throughout the entire organization. It does take up more disk space on remote servers, but it beats pulling Office XP across the WAN.
Also, do not rely on DFS's FRS (File Replication Service), it is far too slow. I created a robocopy script that mirrors one main server to all the others.
hth,
Nate
DFS allows me to only have to use one path for all source paths in my packages throughout the entire organization. It does take up more disk space on remote servers, but it beats pulling Office XP across the WAN.
Also, do not rely on DFS's FRS (File Replication Service), it is far too slow. I created a robocopy script that mirrors one main server to all the others.
hth,
Nate
Posted by:
aogilmor
20 years ago
That's an excellent idea, one I wish were in wide practice.
The "low tech" way of accomplishing the same thing is: have a script copy the setup or MSI to the local hard drive, run the setup or MSI, then quit. That way, when subsequent users need to access the source, it's always right there.
Of course, this does waste a bit of space, but disk space is SO cheap now.
what's a GB or 2 between friends. ;-)
O
The "low tech" way of accomplishing the same thing is: have a script copy the setup or MSI to the local hard drive, run the setup or MSI, then quit. That way, when subsequent users need to access the source, it's always right there.
Of course, this does waste a bit of space, but disk space is SO cheap now.
what's a GB or 2 between friends. ;-)
O
ORIGINAL: nmead
I used DFS with hidden Apps shares that are accessible to all users/computers. I then lockdown the filesystem to the groups that actually get the applications
Posted by:
MSIMaker
20 years ago
There is also a property to set the msi to use a locally cached copy to self repair. You can also set Source Locations table within your msi if you have a limited number of install points on the network and assigned fixed locations that way.
Posted by:
adaptability
20 years ago
Hi,
can you tell which is that proeprty which will use locally cached copy
can you tell which is that proeprty which will use locally cached copy
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.