Software Deployment

The package does, or the application? What is the exact 'problem' you are trying to solve that requires a mapped drive?

Mapping drives in packages isn't normally a good idea. For example, how do you intend to manage drive allocation conflicts, i.e. if the user has already mapped the drive in question? If you need a source for, say, files to be copied from, UNC is fine.

Remember that if you are deploying by conventional means (e.g. Group Policy, SMS, Radia, etc) the System account has no access to the network.

deploying by conventional means (e.g. Group Policy, SMS, Radia, etc) the System account has no

The in-house developed application [that needs to be packaged] has desktop shortcuts that point to a static drive mapped share to launch the app. The application exe actually resides on the server share.

Quick question: Currently, my shortcuts point to K:\Application\App.exe, can I replace the K: with \\servername\sharename\Application\App.exe? Would that be ok to do, or would that have issues once we install and try to launch the app?

ORIGINAL: aek
can I replace the K: with \\servername\sharename\Application\App.exe? Probably. Why not create a s/c on YOUR desktop and test it? It could be, however, that your developers have hard-coded that path into the EXE. If so, greet them warmly by the throat and remind them that's 2008, not 1988. :)

BTW, if it was me, I'd create separate properties for the server and share names and use the properties instead of hard-coding them to the shortcut. That way, if (sorry, when) the server or share is changed, new installs could, if need be, be done from a command line which specifies the property values, temporarily obviating the need to re-compile the MSI. The same applies for your projects which use IP addresses and such.

ORIGINAL: aek

Quick question: Currently, my shortcuts point to K:\Application\App.exe, can I replace the K: with \\servername\sharename\Application\App.exe? Would that be ok to do, or would that have issues once we install and try to launch the app?


Assuming your shortcut(s) will reside somewhere in the Start Menu then one problem I can see with using UNC paths in shortcuts is that if the UNC path to the target is unreachable, then you will encounter problems with *significant* delays opening the Start Menu as the system tries (in vain) to refresh the Icon Cache from the network location. This behaviour seems to be specific to UNC paths rather than with mapped drives.

One way to avoid this problem is to manually create a shortcut with the UNC path as the target and then taking the resultant .lnk file and including it in the package. You then create a shortcut to the .lnk file in the package. (An additional benefit here is that you then have the option to make the newly created shortcut advertised which might not otherwise have been possible).

Regards,

Spartacus

ORIGINAL: spartacus

ORIGINAL: aek

Quick question: Currently, my shortcuts point to K:\Application\App.exe, can I replace the K: with \\servername\sharename\Application\App.exe? Would that be ok to do, or would that have issues once we install and try to launch the app?


Assuming your shortcut(s) will reside somewhere in the Start Menu then one problem I can see with using UNC paths in shortcuts is that if the UNC path to the target is unreachable, then you will encounter problems with *significant* delays opening the Start Menu as the system tries (in vain) to refresh the Icon Cache from the network location. This behaviour seems to be specific to UNC paths rather than with mapped drives.

One way to avoid this problem is to manually create a shortcut with the UNC path as the target and then taking the resultant .lnk file and including it in the package. You then create a shortcut to the .lnk file in the package. (An additional benefit here is that you then have the option to make the newly created shortcut advertised which might not otherwise have been possible).

Regards,

Spartacus


You don't want to do it that way, the problem with that is that it's impossible to trouble shoot the shortcut from within any MSI editing tool because all you have is a lnk file in the installation. What you want to do is this, set up a property WkDir in the property table and set it to the directory of the EXE you want in your shortcut, t:\networkfolder\, then in the shortcut table in the WkDir column for your shortcut enter WkDir (no square brackets no quotes). Then create another property, EXEPath, with the full path of your network EXE, t:\networkfolder\exename.exe. In the Shortcut table in the same row you just entered the WkDir in, enter the [EXEPath] with the square brackets in the Target column.

As for how to connect t: drive to \\server\share, many ways to do this, vbscript, bat file etc. run as a CA. Probably best to do this outside the package -- IMHO if T: is a standard drive it should be set by logon script or GPO.

Good luck and let us know how it goes.

square brackets in the Target column

Owen and all:

Thank you for the help. I followed the best practice advice, and have requested to have the drives mapped via login script, or manually. [We can do it as we have limited users in a limited area].

The Wkdir property method worked fine.

Thank you all !

ORIGINAL: aek

square brackets in the Target column
Thank you for the help. I followed the best practice advice, and have requested to have the drives mapped via login script, or manually. [We can do it as we have limited users in a limited area].
The Wkdir property method worked fine.
Thank you all !

You are welcome...if you liked the post, please rate it! :-)
OG