We are trying to patch our clients using the ‘Network Deployment’ method, but everytime this fails.
From analysing our build, it appears that Office 2000 Premium was originally installed, SR1a was then rolled out as a patch on top of this and finally this was then upgraded to Office SP3, again as an update.
I can run an office repair on a machine manually and it will accept the original Office 2000 Premium installation source Data1.msi, but if I tell BES to use this, when prompted, during the Office patching each time the patch reports back failed. I have also tried using both the SR1a and SP3 installation sources but again each of these fail.
If I un-install Office 2000 through Add/ Remove programs and re-install it using any of the above versions (it doesn’t matter which), then try and patch using BES specifying the same installation source it is successfull. The only problem is this requires a change to all desktops and there are thousands in our environment…!
The problem with Office network installs is usually with the Office update program (which is running as the SYSTEM account) getting access to the shared CDs. See http://support.bigfix.com/cgi-bin/kbdirect.pl?id=129 for more information.
I have setup four shared installation points: Office 2000 Premium, SR1a, SP3 and one with all three updates slipstreamed into one. I have granted access to ‘ANONYMOUS USERS’ and have also created ‘null session shares’.
If I try to patch our current build the updates fail, but if I uninstall the current installation and re-install it from any of the above installation points I can patch the machines succuessfully, so access to the installation points is ok.
My thinking is that because each of the three componets in the build was installed from a differnet location and at a different time & date that Windows is getting confused when looking for the original source.
Here is an issue that we have run into before that may provide some insight.
Create administrative install of Office on network share.
Install Office from that source to workstation
Apply Patch A to adminstrative install.
Apply Patch A to office install on workstation as a network install. - sucess
time passes
Apply Patch B to administrative install point on network.
Apply Patch B to office install on workstation as if it was a local install. - sucess
time passes
Apply Patch C to administrative install point on network
Attempt to apply Patch C as a network install to office install on workstation. - Fails
Once we sucessfully patched Office as a local install, the locally cached MSI gets out of sync with the MSI on the administrative install point and future attempts to patch fail.
We would fix it with an MSI /X {PID of office product} /QN to uninstall followed by a fresh install. We played around with using /F REINSTALLMODE=vomus SOURCELIST=“path to admin install” but we never could get it to fix the issue.
We got away from the administrative install for the above reason. Our current approach is to cache the entire install locally then perform a Network Install from the locally cached files. All subsequent patches are Network Install method where the network path is actually a path to the locally cached install files. Works expecially well for laptops but it does double the space required on the drive.
I don’t know if this is what is happening for you or not but it is a direction to look in.
Office 2000 and Admin installs just don’t seem to sync up, from lots of research and so much testing I could have reinstalled our office installs manually quicker, I have found that it seems using msiexec command line method does not copy down all the files needed for BES to verify a patch is done.
We switched from a admin install to a network install, just be the reassignment task, made a network install share, and pointed the machines at that. There a dozen machines that needed a manually network reinstall but it was pretty painless.