MSI Installation :: The feature you are trying to use is on a network resource that is unavailable

Lacks's picture
Lacks
October 8th, 2009

Hello,

This query is in concern to installation of MSIs.

Backgroud-

I have one folder in which 3 subfolders have each different MSI means in total 3 MSIs.

a)  ABC.MSI [Lets suppose ABC as an Application name]
b). Hot Fix.MSI
c). DEF.MSI [Lets suppose DEF as an Application name]

B i.e hotfix is dependant on A [ABC]. [explained below]

Install.xml has been written as-

<Run>

<Exec>%SystemRoot%\System32\Msiexec.exe /i "#PackagePath# \ FOLDER NAME \ SUB FOLDER NAME1 \ ABC.msi" transforms="#PackagePath# \FOLDER NAME \SUB FOLDER NAME \ XYZ.mst" /qb! /l* C:\Build\Logs\ABC.log</Exec>

</Run>

<Run>

   <Exec>%SystemRoot%\System32\Msiexec.exe /i "#PackagePath#\ FOLDER NAME \ SUB FOLDER NAME2 \Hotfix.msi" /qb! /log C:\Build\Logs\Hotfix.log</Exec>

 </Run>

 

  <Run>

   <Exec>%SystemRoot%\System32\Msiexec.exe /i "#PackagePath#\ FOLDER NAME \ SUB FOLDER NAME 3 \DEF.msi" transforms="#PackagePath#\ FOLDER NAME \ SUB FOLDER NAME 3\QWB.mst" /qb! /log C:\Build\Logs\DEF.log</Exec>

  </Run>

  <Run>
   <Exec>%SystemRoot%\System32\ICacls.exe "%ProgramFiles%\ FOLDER NAME \ SUBFOLDER NAME \ SUB SUB FOLDER NAME " /Grant Interactive:M</Exec>
  </Run>

//Just Above command is to give special access to SubFolder Name2 [created in Program Files > Folder Name 1 > SubFolder Name 2] and give access rights of Interactive group.

Issue-

On a clean built machine, when install.xml is executed-

1. It runs first MSI and installs ABC application nicely.

2. It runs second MSI and pop up comes that-

---------
The feature you are trying to use is on a network resource that is unavailable.

Click OK to try again, or enter an alternate path to a folder containing the installation package 'data1.msi' in the box below.
---------
** This  pop up comes up with second MSI name and in popup down in Browse window, path seems to be incompleted and not as it is defined in INSTALL.xml.

In browse window, it comes with-

#PackagePath#\ FOLDER NAME \ SUB FOLDER NAME2  [Please see above second msi in install.xml]

And when I browse the path to SUB FOLDER NAME 2 and select HOTFIX.msi and click OK, it installs hotfix.MSI.

3. Lastly, It runs third MSI and installs DEF application nicely.

REGISTRY VALUES:

I checked registry values in-

HKEY_LOCAL_MACHINE > SOFTWARE > MICROSOFT > WINDOWS > CURRENT VERSION > UNINSTALL

and I found all MSI

DEPENDENCY:

I can not install second MSI straight forward. Before installing second msi [hotfix] I need to install first MSI and then it installs. If I install secone MSI, it gives some strange error.


NOTICEABLE::

If I remove all applications by amending install.xml and replacing /i with /x then each application is removed from REGISTRY as well.
 
But when I try to install again while changing /x to /i, then it installs all three MSI with out any error prompt.

I think that it creates some path value for second MSI from previous installation and uses the same path for installation and uninstallation for future purpose.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is the case scenario at the moment and I tried to explain.

Can some one  suggest or recommend me how to sort out this issue?

Thanks & Regards,
 

Filed under: ,
0 votes
nac's picture
nac
6 weeks 3 days ago

MSI Path

This message comes when Installer is not able to find MSI at mentioned location. You can try making local cached copy of the source before starting installation. Can you elaborate more about the type of package and hotfix? I wonder how hotfix is making entry registry even after giving installation error message.

You have created log for hotfix .msi installation,has installation created any log for hotfix.msi? we can get hint from that regarding issue.

I dont know how IMPOSEBLE spells

0 votes
VBScab's picture
VBScab
6 weeks 3 days ago

I don't know if I've mentioned it before...

...but have you considered using ProcMon to see what path the process is trying to access when that message pops up?

Have you tried basic trouble-shooting, like moving the MSI to a different location? Or using short names for the paths?

Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.

0 votes
EdT's picture
EdT
6 weeks 3 days ago

Once again I will refer you to MSI.CHM

I have attached an extract from the help file MSI.CHM
In some situations, the original source of the MSI being patched or upgraded is required for successful completion of the patch or upgrade process, and the extract below shows the typical reasons for this.
One simple way to test whether this is the case, is to copy your original MSI to the local hard disk of your test machine, then install it from there, then try applying the second MSI. Since the source path of the first MSI is now local and still available, you should not get the error.

Finally, if you turn on verbose logging for the installation of the second MSI, the log may well tell you why the original source is required.

 

How can I prevent my patch from requiring access to the original installation source?

It is not possible to eliminate all circumstances under which the application of the patch may require access to the original installation source.

 

 

Adhere to following points to minimize the possibility that your patch will require access to the original source:

  • Prior to Windows Installer version 2.0, the application of a patch required access to the original installation source.
  • Use whole-file only patches. This eliminates the need to create binary patches for all previously released versions of the file. Note that whole-file patches will generally be larger in size than binary patches. You can easily set a patch to be a whole-file patch by authoring the IncludeWholeFilesOnly property with a value of 1 in the Patch Creation Properties (PCP) file.
  • Ensure that none of your custom actions access the original source location.
  • Ensure that the ResolveSource action is conditionalized so that it only runs when needed or alternatively is not present at all.
  • Populate the MsiFileHash table for all unversioned files. The Windows Installer SDK tool, Msifiler.exe, can easily do this for you.
  • Ensure that all files have the correct version and language information. The Windows Installer SDK tool, Msifiler.exe, can easily do this for you.

 

 

Source Requirements when Patching

 

Access to the original installation sources may be required to apply the patch in the following cases:

  • Prior to Windows Installer version 2.0, the application of a patch required access to the original installation source.
  • The patch applies to a feature that is currently run from source. In this case, the feature is transitioned from the run-from-source state to the local state.
  • The patch applies to a component that has a missing or corrupted file.
  • The patch applies to a file in a component that also contains unversioned files with no MsiFileHash entries. A populated MsiFileHash table is required to prevent unnecessary recopying of unversioned files from the source location.
  • The patch was applied with a REINSTALLMODE of amus or emus. This option is dangerous in that it will perform file copy operations regardless of file version. This can lead to down-reving of files and will almost always require the source. The recommended REINSTALLMODE value is omus.
  • The cached package for the product is missing. The cached package is needed for application of the patch. The cached package is stored in the %windir%\Installer folder.
  • The package is authored to make a call to the ResolveSource action. This action should generally be avoided or conditionalized appropriately because its execution will always result in an access of the source.
  • The package has a custom action that attempts to access the source in some manner. The most common example is a type 23 nested installation custom action.
  • The patch package consists of binary patches that will not apply to the current version of the file on the machine.

 

 

Consider the following example where Windows Installer requires access to the original source when applying a patch:

  1. Install RTM version of the product Example.
  2. Apply patch Qfe1.msp to the computer. This patches version 1.0 of Example.dll to version 1.1.
  3. A new patch, Qfe2.msp is provided, which updates Example.dll to version 1.2 and obsoletes Qfe1.msp. However, the patch was only created to target version 1.0 of Example.dll because it was generated using the RTM version of the product. Example.dll version 1.2 includes the fix contained in Example.dll version 1.1, but the .msp file was generated between the RTM and QFE2 images. So, when Qfe2.msp is applied to the computer, Windows Installer will need to access the original source. The binary patch for Example.dll cannot apply to version 1.1; it can only apply to version 1.0. This results in the Installer recopying version 1.0 of Example.dll from the original source location so that the patch can be applied successfully.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

+1 (1 vote)