Office 2007 install via config.xml - DO NOT REMOVE 2003?

[wfiel36849]

The environment I am working with has standardized on Microsoft Office 2003.
The testing phase that we are performing has not certified the entire Office
2007 yet but there are components that we would like to distribute because
they have passed our certification testing. I understand that both suites can
co-exist with minimal issues.. My main conern right now is that we would like
to use the config.xml to distribute the components as opposed to the
administraive install via the MSP.

I have created a customized config.xml that will install Infopath 2007 and
Outlook 2007 from the suite. The issue I'm having is that it automatically
uninstalls the entire 2003 suite that exist on the workstation prior to the
installation. In the admin setup, you can specify to leave certain previous
version components behind. Is this feature also available in the config.xml
but it is not documented?

I am pursuing a possible admin/config.xml installation via scripting to
handle this scenario but I would like to know if there are undocumented
settings for the config.xml that may help me with this situation so I don't
have to create a script to mock-up the installation we are needing.

 

[wfiel36849]

To Clarify what I am asking, I would like to use the config.xml method for
installation of 2007 because we are trying to move away from the previous
administrative install method.

My Config.xml file installs InfoPath 2007 and Outlook 2007. I would like to
remove only those two components from the Office 2003 installation that
currently exist on the workstation. At this time, it removes the entire
Office 2003 suite installation before installing only InfoPath 2007 and
Outlook 2007. We have not certified Word, Excel, or Access so I would like
those to remain on the workstations from the Office 2003 Suite until we deem
they are ready for distribution.

 

[Eric A.]

I don't think you can choose individual office apps from within the suite to
keep and which to remove using the config.xml. The Config.xml is quite
limited in its functionality.

I would strongly recommend reconsidering using the OCT method of configuring
your automatic installation. You state, you are wanting to use the config.xml
method because you are trying to move away from the admin install method. It
is no longer possible to use the admin install method with Office 2007. MS
has decided to also move away from the AIP (Admin Install Point) method with
2007. You can no longer setup an AIP using “setup.exe /a†like you could with
previous versions of Office. Armed with this knowledge, is there any other
reason why using the config.xml would be a better option than the OCT in your
environment?

 

[wfiel36849]

I have created an OCT file to install Outlooks 2007 and InfoPath 2007 which
leaves the remaining components of the 2003 Suite available on the
workstation except for the newer version counterparts. This is the first
phase of our planned rollout. I simply run the MSP with the setup.exe
/adminfile switch.

The second phase, once the remaining components such as Word, Excel, Access,
& Publisher will be rolled out at a later time. All of this needs to be
automated with no user intervention required. If I try to use the OCT --> MSP
file method for a setup that will install all of the components and remove
the 2003 counterparts in the process at a later time, I receive a setup error
that "The /adminfile command-line option can be used only during initial
installation of the product."

We do not utilize Active Directory/Domains and our primary network resource
is Novell and Altiris. Altiris is the method we use to deploy packages.
Having the source available on a file share is not a current option. We are
dealing with two deployments of specific components during two seperate time
frames due to a certification and testing process and I found the config.xml
to be easily accessible so I was pursuing that path...

If we use the MSP through the updates folder option, we run into the issue
that when the additional components are installed, the setup requires user
interaction.

 

[wfiel36849]

In my testing I have been able to use the below method to achieve the results
we are looking for but I don't like the idea of having to use both methods to
accomplish the end results...

Office 2003 (FULL SUITE Exists)

MSP installation of Office 2007 Outlook and InfoPath : Removes Outlooks 2003
& InfoPath 2003.

at a later time...

Install Office 2007 Suite on workstation via the config.xml method for the
full suite.

results..

All Office 2007 components are working and available. Issue: Access 2003,
Excel 2003, and PowerPoint 2003 are still on the workstation. This can be
cleaned up by using the msiexec.exe /x command for the Office 2003 GUID which
removes the Remaining Office 2003 components.

To me, this method works but it seems to much like a hack to me!

 

[Eric A.]

Hi Wfiel,

For the second phase.....
After office 2007 has already been installed if you would like to make a
change to the install automatically (like adding a feature) the correct way
to do this is to create a new .msp file with only the new changes in it (the
new features you are adding/and what 2003 apps to remove/save). Then this new
..msp file you will NOT run with Setup.exe /adminfile. This second .msp can
just be run either by double-clicking, or it you are deploying use the
command "msiexec /p newconfig.msp".
You mention...
"If we use the MSP through the updates folder option, we run into the issue
that when the additional components are installed, the setup requires user
interaction."
I'm assuming you mean that when you are trying to add additional components
to a pre-existing office 2007 install, via this second .msp file (not the
orginal one) it requires user interaction. If my assumption is correct,
again, I would recommend pushing the second configuration .msp using the
command "msiexec /p newconfig.msp". Also... you can get that to run entirely
silently by using the /qn switch at the end.. ie.. "msiexec /p newconfig.msp
/qn". Please let me know if I am not clear.


You mentioned.. "Having the source available on a file share is not a
current option."
That is perfectly fine with Office 2007 because the entire source gets
cached to the local drive. With office 2007 the local installation source or
msocache is forced, so all of the machines will have access to the source
locally.

 

[wfiel36849]

You're explanations are very clear. One question; as I will test this out
tomorrow.
When using the /p with the new msp file, does the original source location
need to match for the second configuration at a later time or can it use
source in a different location?

 

[wfiel36849]

Doh, nevermind! I saw you answered that in the previous post! Thanks again.

 

[wfiel36849]

I followed your instructions and the end results are great. It is similar to
the MSP first, config.xml second for the remaining components. Using 2 MSP
files for configuration is obviously the better option out of the two! Can
you help me with one more thing?!?

Pre-existing : Office 2003 Full Suite and Access 2000

The first MSP is set to install Outlook and InfoPath 2007 but it is told to
leave everything from previous versions except for the previous version
counterparts.

The second MSP is set to install all Office 2007 components and remove all
previous versions of all remaining components except for Access. We need to
keep previous versions of Access on the workstation.

When the first file is applied with the /adminfiles switch, everything goes
well!

Applying the second file with the /p switch installs the remaining
components but it does not un-install Excel 2003, PowerPoint 2003, Word 2003
even though the second MSP tells it to un-install them.

I thought about doing a msiexec /x as an additional command-line in the MSP
but that would remove the entire 2003 suite and I need to keep Access 2003,
Access 2000, and the additional Access 2007 on the machine! Do you know of a
way to accomplish this?

 

[Eric A.]

Well you are right that the second configuration .msp that you deploy will
not remove office 2003, nor can you run a command from the configuration file
either.

You are also right that if you do a msiexec /x it will get all of Office
2003.

I don't know what version office 2003 you are running either. In my test
environment I am running Office 2003 Professional. My guid is
{90110409-6000-11D3-8CFE-0150048383C9}. If your Guid is the same you can use
step two just as I did. If your Guid is different you will have to change
that part.
You can find your guid here...
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

It will be similiar to mine.... on the right side in regedit confirm by
looking for DisplayName



Here is what I have done to repro what you are doing.

#1 Created an .MSP that upgrades Outlook and Infopath. (This works to remove
the previous versions as well)
#2 Running the following command that will remove 2003 Excel, Publisher,
PowerPoint, and Word for Office 2003 and it will leave Access.

MSIEXEC /I {90110409-6000-11D3-8CFE-0150048383C9}
REMOVE="EXCELFiles,PubPrimary,PPTFiles,DocumentImagingUtils,XDOCSFiles,WORDFiles"

#3 Running a second .msp that installs the other Office 2007 features.