Office 2010 - Adding features with OCT MSP file not working
I am attempting to add Access to already installed copies of Office 2010 ProPlus. The original install was pushed with a Dell K1000 customized (OCT) with it's own MSP file in /updates.
My problem is, I am now trying to add Access with a different MSP file. If I run the new MSP file from the desktop of my test machine everything runs and installs fine. Comparing the install before and after running the MSP I see Access is installed as well as VBA (needed for Access). However, this will need to be scripted in my environment. So I open up command and run msiexec /p custom.msp /qb and the minimal UI goes through the motions just the same as when I double clicked the file. Except no end result, no Access no VBA. Am I missing something?
Answers (2)
since you ask, the network install point is a bit diff in the newer versions. when you do an install, from wherever its installed from, it copies all the source to C:\MSOcache
It does the actual install from here, this solved the issue of people doing network installs and not installing all features. (install on firstuse...)
I have never yet used the network install point setting.
Also, DONT put your MSP in the Updates folder. just incase you ever need more than one.... use the setup.exe commandline to point to the correct MSP (and confg file if needed)
Good luck
Top Answer
For modifying an install, I would not use the MSP.
use the setup.exe /modify ProductName /config "yourgucci.xml"
I find that a lot more reliable. Search any of the forums for the weblink to the Office site to fully explain the options.
Comments:
-
Microsoft's own site says OCT is the recommended method of adding features. https://technet.microsoft.com/en-us/library/Ee656738(v=office.14).aspx - CPC_IT 9 years ago
-
read it a little bit slower and with your Microsoft hat and glasses on... its not immediately clear, but with hindsight, its crystal clear...
Read the top two lines in the table, using the OCT (MSP) and the Config.xml.
Then read further...specifically this bit about the config XML...
"You can also use the Config.xml file for maintenance operations such as adding or removing features, and repairs and uninstalls. To do this, you must run Setup again from the original source."
Now from my own experience...
The MSP is best used to do the initial install (in conjunction with the config.xml) and then manage and maintain the install with config.xml(s) as needed. - Badger 9 years ago-
HA! I did in fact need my Microsoft glasses on... I read through the entire article and I've come to the same conclusion... Use MSP for initial installation then use XML for future customizations. Might I ask, while I have your attention. This is my first time performing a mass office installation. Why is it necessary/recommended to use a network installation point? Other then saving local disk space (which is usually abundant) you can simply customize with a XML. I've deployed to a test group with just a MSP and no Network install point. Should I go back and adjust that with an XML? - CPC_IT 9 years ago
