6 replies to this topic

[txprphan]

First please forgive my ignorance . I have actually been using VSI for some time now, but now I need to put my understanding of it into high gear. Here's hoping someone can help.

My limited experience with VSI is just using it to create the Setup pkgs--I didn't need to learn more until now. My situation is this: My company is now starting to move to Windows XP except for the users of our internally-built software, the network admins want to move them from admins on their own machines to "Restricted user" auth 'cause too many of them have abused machines with junk software("Hotbar", etc.). I as a programmer have to try and live within that--meaning we still need them to be able to run the company software and get on demand updates as problems are found and fixed, but can't have them downloading and installing the latest fad software. Right now, most of the machines are Win2K and the users have administrative auth on their boxes. When the users dbl-click the program icon, they actually run a "shell" program which checks a network folder for the most current copy of the .exe and associated .dll & .ocx files. Updates are done in this shell program and then it starts the main pgm right before it ends. Thus I can tell my users when I fix a problem, to just log out of the pgm and back in to get the updates. Enter WinXP and it's "Restricted User" auth and this scenario doesn't work. The shell seems to update the files correctly, but the main pgm starts and gets a "429 ActiveX component can't create object." Ugh. After lots of emails to friends, newsgroup posts, etc. many fingers point to VSI.

So I have many questions: Can VSI do what I need? After reading many of the help files, I get the impression that it can do it, but the terminology leaves me more confused. "Patch" vs "Update"? "Minor update" vs "Major update"?

Please help.

[Stefan Krueger]

Not sure I understand your problem but a restricted user cannot install an ActiveX control, unless it's done with "elevated privileges" which is possible in MSI if the package is managed (e.g. assigned via group policy).
Note however that the elevated part of the install will most likely not have network access, so you may have to download the files to a temp folder with restricted rights, then run the update from there in elevated mode.

[txprphan]

Thanx for your response. I have 3 questions that might help turn the light on for me:

1. What do you mean by "the MSI Package is managed"?
2. Download what files?
3. How would I 'activate' the updating mechanism?

[Glytzhkof]

1: As Stefan writes a managed application is assigned to a user / computer from Active Directory. This means that the system administrator has said that "this package can be installed by regular users" - hence the use has elevated priveledges, or temporary admin rights, for the duration of the installation. Note that ONLY the MSI package has these rights. The user cannot "do admin stuff" while the setup is installing.

2: Download all files you need to install to the local computer (the elevated parts of an MSI setup runs in system context and hence cannot access mapped network drives etc - there is no user context. Pretty much the same as scheduled tasks that run with the SYSTEM windows account)

3: Assign the setup using active directory, or add the setup to each users logon script. In the latter case you won't get elevated priveledges I believe (unless you enable the "always install elevated" policy (look this up in the Windows Installer SDK).

Edited by Glytzhkof, 27 January 2004 - 22:41.

[txprphan]

Thanks for your quick response! I think I'm pretty close to the understanding I need to implement this, but I've a couple more questions if I could beg your indulgence.

1. Do I have to update the full installation MSI package every time I update the DLL in order to get Windows Installer to update the DLL on the user's machine?

2. I can easily find a way to push/pull the updated MSI file down to the user's machine. But when the user exits the program and restarts it, will Windows Installer 'intervene' when an updated MSI is found and install the new/updated files?

[Glytzhkof]

1: As far as I understand what you are asking. If it is a small application, use a major upgrade project

2: Not sure about this one. I have never assigned an MSI through active directory. I assume that since this is effectively a policy that the MSI can be force-installed.

[txprphan]

Ok, I now have a program that shells the following command:
"MSIEXEC /fo Install.msi" based on criteria that is otherwise determined in the program--not important for this discussion. That command starts and runs, but what I have found is that for some reason it is not updating all the files if there is an "older version". For example, I have used Orca to confirm that version 2.1.0.46 of class.dll is in the .msi file, but after I run the "msiexec /fo" command, I still have class.dll, version 2.0.0.45 on disk. What gives? Do I need to reboot to see it? What am I not doing to get the newer version installed? I have also tried "/fa", "/fe" and nothing seems to work.

Please help!!!