Previous versions of Office won't uninstall when deploying Office

[Will73]

I've been fighting with an issue for some time now. I've been trying to
deploy Office 2007 plus via Group Policy (we don't own SMS). I'm using the
config.xml file to customize the install. Everything installs fine, but it
doesn't uninstall previous versions of Office. I even wrote a custom script
that does it, but the config.xml file won't call it when using GPOs. This is
a problem for us since the previous versions of Office were installed
manually.

Here's my config file.

<Configuration Product="ProPlus">
<Command Path="\\servername\sdg$\MS\Office\2007\OfficeVersionCheck.exe" />
<ARP ARPCOMMENTS="This is the Office 2007 Professional Plus Installation."
ARPCONTACT="Company IT Helpdesk" />
<USERNAME Value="Company Name" />
<COMPANYNAME Value="Company Name" />
<Display Level="Basic" CompletionNotice="Yes" SuppressModal="No"
AcceptEula="Yes" />
<Logging Type="standard" Path="%temp%" Template="Microsoft Office
Professional Plus Setup(*).txt" />
<PIDKEY Value="PID#" />
<INSTALLLOCATION Value="%programfiles%\Microsoft Office" />
<setting Id="Reboot" Value="IfNeeded" />
<SOURCELIST Value="\\servername\sdg$\MS\Office\2007" />
<OptionState Id="ACCESSFiles" State="local" Children="force" />
<OptionState Id="EXCELFiles" State="local" Children="force" />
<OptionState Id="OUTLOOKFiles" State="local" Children="force" />
<OptionState Id="PPTFiles" State="local" Children="force" />
<OptionState Id="WORDFiles" State="local" Children="force" />
<OptionState Id="XDOCSFiles" State="local" Children="force" />
<OptionState Id="SHAREDFiles" State="local" Children="force" />
<OptionState Id="TOOLSFiles" State="local" Children="force" />
</Configuration>

Has anyone successfully deployed Office 2007 via Group Policy?

HELP!!

 

[Will73]

One thing I fogot to mention. I also tried creating an .MSP file and
dropping that in the Updates folder in the install path. That didn't work
either.

This has been very frustrating. I would've been nice if Microsoft
remembered the small businesses that don't own SMS when they released this
version.

 

[Bob Buckland ?:-\)]

Hi Will,

Using GPO for deploying Office 2007 isn't one of the 'favored' methods <g>. GPO deployments can't use .MSP files.

As the original installation wasn't by GPO, your computers may be considered to be in an 'unmanaged' state, which can further
complicate things.
http://support.microsoft.com/kb/307803/en-us?FR=1

If you use the new built in Office 2007 Setup.exe, the new setup method does take small businesses into consideration. Basically,
all setup runs are accomplished from the \MSOCache folders and those can be pre-cached to the local machines or made a part of a
drive image and the setup doesn't have much of a load on the network after that.

For GPO deployment the following may be helpful

http://technet2.microsoft.com/Office/en-us/library/2d78959d-977b-40e7-b5b0-9a59c1e483f51033.mspx

=============
One thing I fogot to mention. I also tried creating an .MSP file and
dropping that in the Updates folder in the install path. That didn't work
either.

This has been very frustrating. I would've been nice if Microsoft
remembered the small businesses that don't own SMS when they released this
version.
--
-Will73 >>
--

Bob Buckland ?
MS Office System Products MVP

*Courtesy is not expensive and can pay big dividends*

 

[Will73]

Bob,

Thanks for the response. The links were helpful. I do understand that
GPO's are not the preferred method, but deploying 400+ computers by hand is
not very desirable either. I would like to use GPO's since we don't have SMS
and it would be nice to manage the software to some degree. I have to deploy
to the computer policy as well otherwise people will log into other computers
that are not suppose to have Office installed.

I have the software installing fine. The only piece that is left is that it
just won't uninstall the previous versions of Office. I went ahead and wrote
a custom script that would do this, but the config.xml file won't call it for
whatever reason. Do you have any other suggestions on what I could try?

Thanks

 

[Gerry Hickman]

Hi,

Surely anyone in their right mind would UNINSTALL the old version before
trying to blast a new one over the top?

The other question worth asking is "did you test the uninstall before
rolling out the previous version", if not, why not?

Upgrades are ALWAYS wrong. This includes Windows and Office. The only
way to install Windows is to start with a blank partition, the only way
to install office is to uninstall old versions in reverse order, check
all COM registrations for any bad mappings, check and clean all user
profiles, then install the new one. Then do a test UNINSTALL before
rolling it out to the network.

 

[Will73]

That is exactly what I am trying to do. It will uninstall if I use the
setup.exe file. It will uninstall if I use a custom .MSP file. Problem is
there is no way to uninstall through Group Policy. Since the software was
originally installed manually there is no upgrade path to remove it via GPO.

I would love to run around my company and uninstall all the clients, but
that would take quite some time. It would be better if there was a automated
way of doing this. Your approach is the ideal method, but not always a
practical one.

 

[Gerry Hickman]

Hi,

Ok, if the original installs were "manual", that explains a lot. Here's
something to try, run this script against some random remote boxes and
it should print the 3 key qualifiers for the product. Once we have them
we can test doing an uninstall (if you have a domain admin account?)

Copy and paste this script into a text file called o2k3check.js, then
run it like this

CScript o2k3check.js

Copy and paste the output back here

* look out for line wrap below *

// Get Microsoft Office Products
// You MUST run this under CScript, not WScript.
// one command line arg = computer to check
// no command line arg = local computer

var cArgs = WScript.Arguments;
var cArgsUnnamed = cArgs.Unnamed;
if (cArgsUnnamed.Count > 0) {
var strCmp = cArgsUnnamed(0);
} else {
var strCmp = ".";
}
var oLoc = new ActiveXObject("WbemScripting.SWbemLocator");
var oSvc = oLoc.ConnectServer(strCmp, "root\\cimv2");
getProducts();
oSvc = null;
oLoc = null;

function getProducts() {
// Get key qualifiers for all Office products

var re = /^Microsoft Office/i;
var cProducts = oSvc.InstancesOf("Win32_Product");
trace("Total number of products " + cProducts.Count);
var e = new Enumerator(cProducts);
for(;!e.atEnd();e.moveNext()) {
var oThisProduct = e.item();
var strProductName = oThisProduct.Name;
if(strProductName.match(re)) {
var strProduct = oThisProduct.IdentifyingNumber + " : ";
strProduct += strProductName + " : ";
strProduct += oThisProduct.Version;
trace(strProduct);
}
}
}

function trace(strMsg) {
WScript.Echo(strMsg);
}

 

[eugenevr]

I find the whole way the new deployment is being done very
interesting. Suddenly GPO deployment is not as an acceptable way of
deploying Office any more.... Some distasteful words come to mind.
Whilst the "preferred" procedure is sure to work OK (never mind that
you can "customize" far less of the deployment than would have been
the case with OCW alone), it is clear MS did not think this through
properly.

As for uninstalling Office 2003 first (upgrading is ALWAYS wrong????),
most of us lowly techies (esp those who consult to other companies who
most of the time do *not* have pristine setups), cannot always start
with a clean slate. In short, I've had no issues doing in-place
upgrades from Office 2000->XP->2003. It is not ideal I concur, but it
is the reality many of us work with. And what about user setttings
specific to Office; if I remove an old version and do a fresh there
are always some things missing, and we then are faced with touching
the desktop manually or having to find all kinds of scripting
solutions as workarounds. (Thanks for posting the js by the way!)

MS has given us a wonderful product in Office 2007, it's people ready
but not exactly IT ready. Once again: there are numerous of our client
base that cannot afford SMS/SCCM, where we have been using GPO
extensively to deploy software (esp Office 2003); to curb the use of
GPO in deploying Office 2007 seems almost unbelievable. There are
numerous posts and blogs about this issue and it is sure to stir up
even more emotion as sysadmins start to realize the deployment toolset
is not as refined as it should be.

 

[Gerry Hickman]

Hi,

It's been the case for a long time that Microsoft products are becoming
less friendly for the big corporate IT networks. There's thread over on
the MSI newsgroup (Vista and DCOM) that echoes the same problem but from
a different angle.

The main Microsoft focus appears to be the "home user who is a member of
the Administrators group", and who interacts with the computer by
"clicking" things.

If you look at all the Microsoft help files, ResKits and MSDN
collections since 1999, you'll note that all the advanced topics are
being removed and replaced by meaningless rubbish. Here's an example
when you search for "An attempt was made to reference a token that does
not exist." on Vista you get this from Windows 2000:

<http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/w2000Msgs/3803.mspx?mfr=true>

"Contact the supplier of the running application."

Great, so I have to contact Microsoft

The Vista help file is another good example. Vista makes extensive use
of Reparse Points, but if you put those words into the help file, it
starts offering help about "Wireless access points"! Clueless and
stupid, just like the so-called "security model" and "virtualization" in
Vista.

No doubt the AIP was seen as a "bit too advanced" for the average
Microsoft Certified Systems Engineer. Likewise they "deprecated" the MSI
provider inside WMI. Again probably seen as a "bit too difficult" for
the kind of people who choose Microsoft? Instead they offer "wizards",
where people are led by the hand like children, and end up with equally
childish results.

The other thing they did was create ".NET Framework" to try and make
programming more "child friendly". Note that for their own products they
stick to native code using C++ and COM, but try to brainwash customers
into thinking .NET is superior, and most of them fall for it. Unbelievable!

 

[Kenneth Hempkins]

I don't think this is "by accident", but by "marketing strategy".

If you want to sell as many SMS-Licenses as possible, find a "killer app"
that will force everyone to use it.
Using Office 2007 to push SMS is just a nother way to screw the customer.
Have you tried to deploy SQL 2005 Express with GPO ?
MSDE 2000 is an msi that deploys without ant problems, but I still haven't
found a way to do it wth 2005.
Expect the exact same behavior with all new products. How can I use a new
product that everyone wants, to push a product that they don't need or want
?

Kenneth Hempkins

 

[Gerry Hickman]

Hi Kenneth,

I agree this is no accident! It's all about political correctness, which
is the same as marketing. Everything must be child friendly and must
look good in a lame TV commercial.

Merge Modules, Manifests, DLL ordinals, kernel mode semaphores,
acquiring process tokens and DCOM permissions don't look good on TV.

I can't stand SQL Server Express, and most vendors I've seen that try to
force it onto workstations don't have a clue how to check for other
software that's already using an instance of it, they just try to blast
their own over the top.

I hacked all my client software to reference a production SQL 2005 SP2
server. I don't want that bloated junk anywhere near my workstations.