/build/static/layout/Breadcrumb_cap_w.png

Can an MSI/MST be "locked out"

Hi - I have packaged something called DNE update which is apparently required for Citrix access over 3G dongles

http://www.citrix.com/lang/English/lp/lp_1680845.asp

Pretty simple msiexec /i msifile /t mstfile etc. - I call it from a VBscript and deploy through SCCM 2007.

The strange thing is whilst it appears to install just fine if I run two machine builds one after the other one always fails doing this package. Yet if I run a rebuild on the same machine on its own it runs fine. In testing if I run the Vbscript it always runs perfectly. Its as if the MSI somehow has a lock in that if a second machine is trying to access it the msi at the same time it fails

I wondering how I can best troubleshoot this - perhaps there's a verbose switch I can add to the MSI file

Thanks

0 Comments   [ + ] Show comments

Answers (7)

Posted by: admaai 13 years ago
Orange Senior Belt
0
Your comman line is wrong, the transform will not be applied.
Posted by: reds4eva 13 years ago
Second Degree Blue Belt
0
msiexec /i MSIfile TRANSFORMS=MSTfile /l c:\temp\MSIfile.log /qb
or verbose
msiexec /i MSIfile TRANSFORMS=MSTfile /l*v c:\temp\MSIfile.log /qb
Posted by: iburnell 13 years ago
Senior Yellow Belt
0
App is installing ok so the syntax must be ok. This is the line from the VBscript

intReturnCode = oWSH.Run ("msiexec /i """ & MSIFile & """ /t """ & MSTFile & """ /qr REBOOT=ReallySuppress",1,True)

As I say strangely if I run two builds (which include this package) concurrently the first appears to install the package the second doesn't. Yet if I do a rebuild after the fact on its own the app installs perfectly. With SCCM packages install from a UNC directory so path for the msi would be a UNC share

I will need to test more but I simply wondered if there was possibility of locking or contention from the source files ?

Thanks
Posted by: timmsie 13 years ago
Fourth Degree Brown Belt
0
App is installing ok so the syntax must be ok.

It definately wont be applying your transform though! Look at Reds4eva's post for correct command line

It shouldn't be getting "locked" either otherwise how could we ever deploy anything via sms/sccm

But when you say it fails, what do you mean what do the SCCM logs and msi logs say?
Posted by: anonymous_9363 13 years ago
Red Belt
0
the syntax must be okIt sort of is. You use '/T' when specifying a transform for an advertised install i.e. with the '/Jx' argument. You must use the TRANSFORMS property when installing, i.e. with the '/I' argument.
Posted by: iburnell 13 years ago
Senior Yellow Belt
0
Interesting I apply /t to most of my packages without problem for response transforms. I used to specify TRANSFORMS= but can't remember why but changed it to /t - seems to work fine !

SCCM just sits there until it times out indicating the package is shouting for something - either syntax or a response of some sort but as I said if I test from system command prompt (which is how SCCM deploys) it always installs fine - that's why I use /qr to see the progress

the package itself does create log file in %temp% so I need to test two machine side by side to see if I can get one to fail and investigate further

Thanks for your input
Posted by: timmsie 13 years ago
Fourth Degree Brown Belt
0
Have you confirmed that your mst's are getting applied? I think you'll find they aren't. The install will run fine without any errors with the command line your using but it wont apply the mst.

Are there any prerequisites that are missing on a machine that fails?
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ