locked
Office 2010 deployment - wont apply custom .MSP file RRS feed

  • Question

  • Hi all,

    I am creating a new deployment environment for our company and having some issues with Office and adminfiles.

    I basically cannot get setup to apply the custom MSP file from my network share, either using MDT application deployment, nor manually using the command prompt once the machine has been built.

    I was also informed by several documents that any patches (which I assume to be MSP's and MSU's) that are present in the \Updates\ folder during setup will automatically be applied. This does NOT happen for me. It completely ignores my MSP when it's in there.

    The error I get when trying to parse the admin file is pretty basic. It just says: "path or file specified with /adminfile did not contain any patches"

    This is the command i'm using: setup.exe /adminfile "Updates\mymsp.MSP"

    I've also tried using the full path: setup.exe /adminfile "\\domain\server\apps\office\updates\mymsp.msp"

    None of that works.

    Any ideas??

    NB. It DOES work when I copy the MSP file to a local disk and execute from there. That adds an unnecessary manual step to my builds though, which I want to be completely automated. It also means I have to create a batch file to copy it locally first.

    Friday, May 20, 2011 12:23 PM

Answers

  • I found the problem with this.

    I was using the generic setup.exe.

    When I used the platform specific setup.exe (e.g. we are using 32bit office so used setup.exe in the x86 folder), the commands worked fine. When using the generic setup.exe I suffered the problem.

    It's weird, since it still works manually using the generic setup file. Just when I deploy it with MDT it doesnt like it.

    • Marked as answer by supermop Tuesday, October 18, 2011 12:38 PM
    Tuesday, October 18, 2011 12:38 PM

All replies

  • The command line should be: \\server\share\path\setup.exe /adminfile ".\Updates\mymsp.MSP" Note the added .\ It cann also be a permisson issue. Are you useing a local administrator account for installation? That account will not be known by the fileserver and not served.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Proposed as answer by Buzz_Lightbeer Thursday, September 22, 2016 8:13 PM
    Saturday, May 21, 2011 1:03 AM
  • if you have your msp in the updates folder of the installation source, you don't need to specify an adminfile parameter at all.
    the catalyst setup engine always looks there by default.
    both types of msp's (customisation msp's and update msp's) can be placed in the \updates folder.

    msu's are not used for office, only for the OS 


    Don

    Saturday, May 21, 2011 6:44 AM
  • Thanks for the replies so far.

    @Nothnagel: I tried all permiatations of the command line but nothing works unless it has a drive letter in front of it, including the prefix ".\"

    @Don: As stated in the original post, when I place my MSP in the Updates folder, it does not apply it. Just starts setup as normal. Like I said, every piece of documentation says that placing an MSP file in the Updates folder should make setup.exe use it. I dont know if I'm using a different version to everyone else, but mine certainly does not do this in any scenario I have tried.

    An easy test to prove this is to set up some basic install options and make it to a silent/basic installation. I've done this various times and each time it just loads the full interactive wizard and forgets all my customisations in the MSP.

    I am sure I'm missing something obvious, but cant think what.

    Tuesday, May 24, 2011 4:17 PM
  • Hi Greg,

     

    do you use a config.xml?

     

    Yes: Please add the following line to the config.xml:

    <Logging Type="Verbose" Path="%TEMP%" Template="Office_2010_ProfessionalPlus_Install(*).txt" />

    No: Please create an empty config.xml and copy&paste the following line:

    <Configuration Product="ProPlusr">
    <Logging Type="Verbose" Path="%TEMP%" Template="Office_2010_ProfessionalPlus_Install(*).txt" />
    </Configuration>

    The above lines are customized for Office 2010 ProfessionalPlus. Then run the setup again, include the config.xml-file:

    setup.exe /adminfile path\file.msp /config path\config.xml

    The setup should write an extensive log to the temp-folder (%temp%). The logfile will show you, if setup can locate the specified msp-file and is able to parse it. If it does not work out, post the logfile here.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by William Zhou CHN Thursday, May 26, 2011 8:36 AM
    • Unmarked as answer by supermop Tuesday, October 18, 2011 12:36 PM
    Wednesday, May 25, 2011 1:28 PM
  • I realize this is an older post, but thought I would add a reply anyway (I was looking for an answer to a different problem, but found this post).  As far as I know, if you have any Office hot fixes in the "Updates" folder, you need to name your custom .msp file to something so that it is read first.  I believe the installer looks for the first file in the folder (numeric, then alphabetic).  So, if the first file is one of the hotfixes, say "appdata-x-none.msp", then it won't read the custom.msp you created.  The easiest fix is to add a "1" to the beginning of the name...1_custom.msp. 
    Thursday, June 23, 2011 7:05 PM
  • I found the problem with this.

    I was using the generic setup.exe.

    When I used the platform specific setup.exe (e.g. we are using 32bit office so used setup.exe in the x86 folder), the commands worked fine. When using the generic setup.exe I suffered the problem.

    It's weird, since it still works manually using the generic setup file. Just when I deploy it with MDT it doesnt like it.

    • Marked as answer by supermop Tuesday, October 18, 2011 12:38 PM
    Tuesday, October 18, 2011 12:38 PM
  • Try with:

    msiexec.exe /p "\\domain\server\apps\office\updates\mymsp.msp"

    Tuesday, September 16, 2014 8:41 PM