Hi Bob,
Office 2003's design is specifically to use Setup.exe rather than install
directly from an MSI directly to solve some problems that
came with earlier versions, and verify completion of all of the steps.
Using just the MSI isn't considered to be a 'supported
method'
http://support.microsoft.com/kb/828377/en-us?FR=1
(in the sequence of events for Setup.exe page of the Office Resource Kit
note the box labeled "important"
I'd guess there are folks using their own methods and 3rd
party deployment tools as well <g>.
OK, from what I can gather their only concern is "system verification", this
doesn't worry me as the same rules apply to any other MSI deployment. In
other words, it's my job to ensure the system is "verified". However, the
language used in that paragraph says "DO NOT", and that's a concern for the
reasons you stated (not fully supported etc).
One of the changes for Office 2003 was the choice to use an Office Admin
Point as the source or to use a Local Installation Source
(MSOCache) to deploy and that is partially where setup.exe comes in.
http://support.microsoft.com/kb/830168/en-us?FR=1
Yes, well I'm not the only one that thinks LIS is a "barmy" (quoted from a
website) idea. It seems like a security risk to me, where they'll end up
with CAB files in their "hidden" local cache that contain vulnerable older
versions of things like EXCEL.EXE? I took one look at the MSOCache and
OSE.exe when Office 2003 was first released and decided to steer well clear.
I guess I'm not following why having setup.ini to store parameters would
be 'messier' than putting the parameters in a batch
file(although you can script or batch run the setup.exe command). Both
batch and ini are text based command lists.
At first I thought SETUP.INI was a good idea, but I have created a tiny
generic deployment tool that can install/manage/uninstall not just Microsoft
products but others too such as Adobe. The Setup.exe for Office is causing
me headaches because I can't use the same calls from the MSIEXEC service;
one example is that my tool can check to see if Office 2003 is already
installed (e.g. from a CD) and then act accordingly such as uninstalling the
mismatched product first and then installing the correct one - useful for
corporate mergers. The other thing is that I want all parameters to be set
in ONE place; I don't want some things set inside SETUP.INI and others in
TRANSFORMs and CMD lines; as I manage Office 2003, Frontpage 2003, Project
2003, that's 3 x SETUP.INI to worry about. With MSIEXEC I can merely set the
properties for all three products at run time. Of course it's still possible
to do the above with Setup.exe, but not in the elegant way I'd like.
and for the Office Web Components there is another consideration,
depending on how / where they might be used
Yes, if I'd known what the "Office Web Components" were a few months back
I'd never have selected that feature for install! ActiveX was always a bad
idea; if you're going to put something on the "web" it needs to work in
browsers other than IE and on platforms other than Windows. Even for
Windows-only, it's a bad idea as the ActiveX tends to go wrong when you've
got non-admin users and tight security settings and by nature you get a lot
of security flaws found in ActiveX which then allow system level access
because of parts of IE being part of the operating system. The steps users
are expected to take in KB828950 and the "licensing considerations" are
enough to put anyone off; life is too short for such nonsense.
Anyway, the links you posted have clarified the issue of Setup.exe vs
MSIEXEC, I think it's worth trying my new MSIEXEC system to see if it works,
and in theory it will also work with Office 2007.
