Alternative Source Location
Probably been asked before, but I can’t find seem the information here or on google, i found information that came close but not a definitive answer – so I’m asking here.
Issue:
Software is installed deployed from SCCM. You run it away from the network, it tries to self hear and asks for the media location = fail, no self heal.
I won’t go into the reasons why I cant(not allowed) download the files locally before installing.
Information I have so far:
I have found MEDIAPACKAGEPATH and SOURCELIST.
Both can be used to set package sources. I have tried using them but they don’t seem to be working correctly. In saying that I haven’t used them bother together, but would you need too?
Using either of the above i was unable to get the MSI to use an alternative source location if it couldn’t find the original it ran from.
Any thoughts would be appreciated .
Keywords for future searches:
Alternative package source MSI location local
Issue:
Software is installed deployed from SCCM. You run it away from the network, it tries to self hear and asks for the media location = fail, no self heal.
I won’t go into the reasons why I cant(not allowed) download the files locally before installing.
Information I have so far:
I have found MEDIAPACKAGEPATH and SOURCELIST.
Both can be used to set package sources. I have tried using them but they don’t seem to be working correctly. In saying that I haven’t used them bother together, but would you need too?
Using either of the above i was unable to get the MSI to use an alternative source location if it couldn’t find the original it ran from.
Any thoughts would be appreciated .
Keywords for future searches:
Alternative package source MSI location local
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
pjgeutjens
12 years ago
You run it away from the network, it tries to self hear and asks for the media location = fail
I won’t go into the reasons why I cant(not allowed) download the files locally before installing.
If you are not allowed to copy the installation sources locally, what source would you then try to repair from when there is no network available?
One option to avoid this issue alltogether would be to use the DuplicateFiles table for any files that would go into user-specific locations. Since Windows Installer only falls back to the original installer when it needs to put files into the user profiles. For all other things it will fall back to the cached version of the msi in the Windows\Installer folder (which gets stripped of all file data).
The idea behind using DuplicateFiles is to put all user specific files in an accessible folder, for example a _user folder in the applications InstallDir, and then, for the files in the user profiles, referencing these 'base' files in the DuplicateFiles table, so instead of wanting to go back to the original MSI at time of self-heal, Windows Installer will just copy over these originals.
PJ
Posted by:
rileyz
12 years ago
Hey PJ,
Great question, and poor explanation from my part. SCCM does download it thru a task sequence (_SMSTS folder) but then removes the source after it has run. Leaving no source files. I have found a webpage (which i have lost, but will find again) which will allow me to copy the files locally.
I guess i can run/install the the MSI locally but im trying to advoid this and be more elegant with my MSI's (:
`R
note: the product is has been blown out into a admin install, stupid microsoft software... (MapPoint).
Great question, and poor explanation from my part. SCCM does download it thru a task sequence (_SMSTS folder) but then removes the source after it has run. Leaving no source files. I have found a webpage (which i have lost, but will find again) which will allow me to copy the files locally.
I guess i can run/install the the MSI locally but im trying to advoid this and be more elegant with my MSI's (:
`R
note: the product is has been blown out into a admin install, stupid microsoft software... (MapPoint).
Posted by:
pjgeutjens
12 years ago
I would say the most elegant solution would be the DuplicateFiles one, but that's personal preference.
As far as the SOURCELIST property goes, it should be just a semicolon-delimited list of locations, so adding the local path where you plan to put the files should do the trick. I haven't tested it though, so if you're having problems with it, I suppose you could also try exporting the relevant keys from HKCR\Installer\Products\<HASH>\SourceList and adding these to your MSI.
PJ
As far as the SOURCELIST property goes, it should be just a semicolon-delimited list of locations, so adding the local path where you plan to put the files should do the trick. I haven't tested it though, so if you're having problems with it, I suppose you could also try exporting the relevant keys from HKCR\Installer\Products\<HASH>\SourceList and adding these to your MSI.
PJ
Posted by:
rileyz
12 years ago
SORTED!
I was just being spanlged. I was applying a transform and also throwing properties below at the MSI, it didnt like having a transform being used and properties in the command line thrown at it. You need all the bits in the transform.mst file. So you cant hack it in at the end as i did.
(example msiexec blah.msi TRANSFORMS=Blah.mst SOURCELIST="C:\source\". This does not work, you need it all in the blah.mst)
We are using sccm to deploy.
Right, MEDIAPACKAGEPATH and SOURCELIST do the job for what i needed it to do. They can be used to specify alternative source locations, ie on laptops when they go off site and some bits need to self-heal or repair etc.
Example:
In the transform.mst add MEDIAPACKAGEPATH="c:\Source Location\SomewhereofMSI\" and SOURCELIST="c:\Source Location\SomewhereofMSI\".
This will add the alt source locations to HKCR\Installer\Products\<product code>\SourceList\ Net or Media.
Should only require of one of the properties above, but i havent tested with just one property yet.
**dont forget to copy the source msi files to the local drive some how (:
I was just being spanlged. I was applying a transform and also throwing properties below at the MSI, it didnt like having a transform being used and properties in the command line thrown at it. You need all the bits in the transform.mst file. So you cant hack it in at the end as i did.
(example msiexec blah.msi TRANSFORMS=Blah.mst SOURCELIST="C:\source\". This does not work, you need it all in the blah.mst)
We are using sccm to deploy.
Right, MEDIAPACKAGEPATH and SOURCELIST do the job for what i needed it to do. They can be used to specify alternative source locations, ie on laptops when they go off site and some bits need to self-heal or repair etc.
Example:
In the transform.mst add MEDIAPACKAGEPATH="c:\Source Location\SomewhereofMSI\" and SOURCELIST="c:\Source Location\SomewhereofMSI\".
This will add the alt source locations to HKCR\Installer\Products\<product code>\SourceList\ Net or Media.
Should only require of one of the properties above, but i havent tested with just one property yet.
**dont forget to copy the source msi files to the local drive some how (:
Posted by:
dandirk
12 years ago
I have used the duplicate file method for self heal and it truly is slick and easy.... Seems like a better solution then changing the source then trying to figure a way to get the msi file on the computer...
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.