Hi all,
I am currently stuck with the task of attempting to register two components from a network location (.ocx & .exe files) which are to be deployed through Active Directory GPO. This has to be a user package as the network location for these files requires the users to be logged on to gain permissions to that area. I have created a .msi file with a stub.exe that runs the registration commands for these files but it doesn't seem to work. I also attempted to embed them as a vbs script within the package created using Wise Package Studio and it still failed. If however I give the user admin privileges on the machine it works. Any help in this matter would be highly appreciated.
Thanks
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Hi Crazy,
this look a little strange to me.
What are you trying to do with a stub.exe in AD GPO deployment scenario?
Did you try to deploy your MSI with a user GPO?
Do you check for the user context and set the per user flag (ALLUSERS="" or 2) in the MSI?
Regards, Nick
Answered 07/03/2007 by: nheim
Tenth Degree Black Belt

Please log in to comment
0
Hi Nick,
I just want to clarify that the only thing this package is supposed to be doing is register two files from a network location. Creating an msi file with a vb script failed due to permissions not being sufficient and hence I tried using the stub.exe to run the registration commands and see if that will solve my problems but still having the same issue. I also attempted to create a custom action in the Wise application but it fails.
I have attempted to deploy the msi using GPO and the only time it works is when I elevate the user privileges which is defeating the whole purpose of creating the msi. I'm stumped on this one and it's just a stupid registration of these two files that were developed in-house and have to be run from the specific network resource otherwise they'll fail.

thanks for the hints but it didn't work. I was thinking maybe I should make this a machine based package that would apply to the workstation through GPO but I wouldn't know what permissions I would have to provide on the network share to allow the machine to access that location.
Answered 07/03/2007 by: Crazy
Senior Yellow Belt

Please log in to comment
0
Hi Crazy,
are you aware, that the registration entries for this components have to go to the HKCU hive, if you install them per user?
That means, they are linked to HKCR, but physically go to HKCU\Software\Classes.
have you tried to put the necessary reg entries into the MSI registry table?
What are you doing with this vb script? Could you post it, so we can get a look on it?

Regards, Nick
Answered 07/03/2007 by: nheim
Tenth Degree Black Belt

Please log in to comment
0
Nick,
To start off, I just want to say I'm sorry and just realized how dumb I am going about this thing. The vbs entries I've been using:

Set objshell = CreateObject("WScript.Shell")
objShell.exec ("L:\Eximbills_V3\ADDON\GIB\ClientGAPI.exe /regserver")
objShell.exec ("regsvr32 /s L:\Eximbills_V3\ADDON\GIB\MSCAL.OCX")
set objshell = nothing

I've been trying to do this the lazy way because I have other things to finish and from your above post I'm realizing that I should have created an msi file with the registry entries and applied that instead. big ouch!

But kindly confirm if I can achieve my goal another way or else I'll just have to input the registry changes that occur when these files are registered in a new package and deploy that instead of attempting to create a package that would run the above commands. Your help in this matter is really appreciated mate.

cheers
Answered 07/03/2007 by: Crazy
Senior Yellow Belt

Please log in to comment
0
Hi Crazy,
you could try to use a CA with msiexec /y and /z to register/unregister.
Something like this:
DllReg 3170 INSTALLDIR "[SystemFolder]msiexec.exe" /y "[#YourReferencedFile1.dll]"
DllUnreg 3170 INSTALLDIR "[SystemFolder]msiexec.exe" /z "[#YourReferencedFile1.dll]"

Make them deferred.

Have never used it with per user installs, but it should work, in a properly authored MSI.

Regards, Nick
Answered 07/03/2007 by: nheim
Tenth Degree Black Belt

Please log in to comment
0
Hi Nick,
I had tried that method in the MSI Script bit of the Wise application and didn't manage to get that one to work. However I did capture the registry changes made to the HKCR and deployed those changes to the client machines and it worked like a charm.

Thanks again for pointing that out in your earlier post, you've really helped a lot mate. I guess working on a dozen applications at one time can cause brain damage in this environment.


Cheers,
Haytham
Answered 07/04/2007 by: Crazy
Senior Yellow Belt

Please log in to comment
0
Hi Haytham,
you're working only a dozen apps in parallel? :-)
Glad to see, it worked out.
Keep MSIing.
Regards, Nick
Answered 07/04/2007 by: nheim
Tenth Degree Black Belt

Please log in to comment
0
using the registry method you mentioned is definately the way to go.

if your running locked down environments users will not be able to run regedit or regserver hence using the registry table is a better option.

it also supports reference counting
Answered 07/09/2007 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity