none
Office Deployment Toolkit Failing to copy .cab files

    Question

  • Hi,

    So I've been at this for a whole day now and can't figure out what's wrong with it.  I'm trying to deploy O365 Pro Plus via a GPO and have downloaded the CTR installation to the NETLOGON share of my domain. I know this is not a good idea, but because our File Server is SAMBA not NTFS, I can't give necessary users permission to access the share to receive the GPO.

    My config file then looks like this:

    <Configuration>
    <Add SourcePath="\\server\NETLOGON\Office2013\Officex64" OfficeClientEdition="64" >
        <Product ID="O365ProPlusRetail">
          <Language ID="en-us" />
        </Product>
    </Add>
    
    <Updates Enabled="TRUE" UpdatePath="" />
    
    <Display Level="None" AcceptEULA="TRUE" />  
    
    <Logging Name="OfficeSetup.txt" Path="\\server\NETLOGON\Officex64\SetupLogs" /> 
    
    <Property Name="AUTOACTIVATE" Value="0" /> 
    <Property Name="ForceAppShutdown" Value="1" />
    
    </Configuration>

    Pretty simple.

    I then created a computer startup script via GPO and used this .bat file.

    @echo off 
    Set RegQry=HKLM\Hardware\Description\System\CentralProcessor\0
    REG.exe Query %RegQry% > checkOS.txt
    Find /i "x86" < CheckOS.txt > StringCheck.txt
    If %ERRORLEVEL% == 0 (
    Echo "This is a 32 Bit Operating system"
    "\\server\NETLOGON\Office2013\Officex86\Setup.exe" /Configure "\\server\NETLOGON\Office2013\Officex86\configuration.xml"
    ) ELSE
    (
    Echo "This is a 64 Bit Operating System"
    "\\server\NETLOGON\Office2013\Officex64\Setup.exe" /Configure "\\server\NETLOGON\Office2013\Officex64\configuration.xml"
    )
    Exit

    So the GPO should be calling "\\server\NETLOGON\Office2013\Officex86\Setup.exe" /Configure "\\server\NETLOGON\Office2013\Officex86\configuration.xml" based on what OS architecture it is.

    When I attempt to run the GPO, everything seems to be good and dandy until this error message pops up like 20+ times before the script just gives up:

    2013/11/12 22:06:24:611::[5856] Downloading cab: \\server\NETLOGON\Office2013\Officex64\Office\Data\v64.cab -> C:\Program Files\Microsoft Office 15\v64.cab

    Can someone give me any leads or ideas at all? I've been researching for a while and haven't found anything useful.

    Thanks in advance,

    V

    Wednesday, November 13, 2013 6:24 AM

Answers

All replies

  • Hi,

    have you granted "Domain Computers" (or Authenticated Users), NTFS read-permissions to the foldershare?

    http://blogs.technet.com/b/odsupport/archive/2012/11/20/office-2013-installation-hangs-at-10-percent-when-installing-from-a-network-share.aspx


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    • Marked as answer by Visokoo Monday, November 25, 2013 4:42 PM
    Wednesday, November 13, 2013 10:18 AM
  • Don,

    I believe Authenticated users by default have read permissions to the NETLOGON share and I'm hesitant to add more groups to it because I get a message saying I'll be removing inherent permissions if I add to the root share directly...don't want to break another GPO that I have going..

    I just stuffed another computer into the OU with the GPO and upon reboot, it looks like it's doing something but when the computer boots back up, nothing is installed. When I check in Program files, I see the Microsoft Office 15 folder created, but there's nothing in there...

    Wednesday, November 13, 2013 5:34 PM
  • Oh, of course, NETLOGON already does. (stupid me)

    is there any further information in the setup logfile upon the client?

    Is there any pre-existing Office installation on the client machine?


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Wednesday, November 13, 2013 9:22 PM
  • No, looks like I misspoke in my previous post.  The startup script from the GPO doesn't seem like it's running even though rsop.msc says that it successfully ran. I don't see anything being copied to the program files folder and nothing appears in my setuplogs as well on the server.

    I have a feeling that my problem is UAC....

    When I run the command as is on the client system:

    "\\server\NETLOGON\Office2013\Officex64\Setup.exe" /Configure "\\server\NETLOGON\Office2013\Officex64\configuration.xml" with no UAC enabled, it installs fully but I have to manually close the box when I see this in the log file:

    2013/11/13 14:49:30:697::[2868] ShellExec: C:\Program Files\Microsoft Office 15\ClientX64\integratedoffice.exe CUSTOMIZE RERUNMODE config "\\corp.avvo.com\netlogon\office2013\officex64\configuration.xml" app root\office15\firstrun.exe  admin=1

    When I run it with UAC, it makes me click OK to access the network resource before it would install it...

    Could it be possible that my script isn't even running because it's not being run as an admin? Or it could have started running, but because there's an extra prompt for UAC, the system manually closes it down because there's no user intervention?

    Wednesday, November 13, 2013 11:00 PM
  • a startup script runs in the security context of the computer account, and as LocalSystem, so it is highly privileged on the client machine and isn't subject to UAC (it is already elevated).

    a logon script runs in the security context of the user account, and so is only as privileged as that user account, and, from memory doesn't use the elevated split-token (in case the user does have the privilege to elevate).

    when you run the script, as a logged-in user, UAC will kick in because you don't run elevated by default when UAC is enabled, UAC will switch you to your (elevated) token.

    put some logging into your script, to find out where it's getting to.

    you can also use psexec.exe (from sysinternals) to open a console session in the security context of the computer account (LocalSystem), and run the script from that session, see if the outcome is different.

    e.g.: psexec -s -I CMD
    you will be prompted by UAC, supply privileged credentials if needed, a console will open, then run your script from inside that console.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Thursday, November 14, 2013 7:48 AM
  • Don,

    Thanks so much for the help so far. I was able to stick "domain computers" in the delegation tab in the GPO and it worked perfectly for 64 bit installs with this code but not for 32bit.

    @echo off
    If %PROCESSOR_ARCHITECTURE% == x86 (
    REM "This is a 32bit Install"
    "\\server\NETLOGON\Office2013\Officex86\Setup.exe" /Configure "\\server\NETLOGON\Office2013\Officex86\configuration.xml"
    ) ELSE (
    REM "This is a 64bit Install"
    "\\server\NETLOGON\Office2013\Officex64\Setup.exe" /Configure "\\server\NETLOGON\Office2013\Officex64\configuration.xml"
    )
    Exit

    But for some reason, it's just not running properly on 32bit installs. I know the if statement is working because it's pulling the correct version down and it's actually copying files into the program files directory, but it's like it never finishes installing or something. The log file says that the "product has been successfully configured" it does not appear in program folders.

    When I try to click "integratedoffice," nothing pops up and I don't see the process executing in taskmanager at all. Any ideas?

    Here's the end of the log file:

    2013/11/15 11:51:36:170::[3904] RobustFileOps::MoveFile: MoveFileEx succeeded
    2013/11/15 11:51:36:170::[3904] RobustFileOps::MoveFiles: 1 backup files were created.
    2013/11/15 11:51:36:170::[3904] RobustFileOps::DeleteFiles: Deleting 1 files, markFilesThatFailToDeleteAsDeleteOnReboot=1.
    2013/11/15 11:51:36:170::[3904] RobustFileOps::DeleteFiles: Deleting "C:\Program Files\Microsoft Office 15\ClientX86\hash.txt.bak".
    2013/11/15 11:51:36:170::[3904] RobustFileOps::MoveFiles: Done with 1 backup files, result=1.
    2013/11/15 11:51:36:170::[3904] RobustFileOps::MoveFiles: Done applying 14 file operations, result=1.
    2013/11/15 11:51:36:170::[3904] ApplyClient : Complete, result=1.
    2013/11/15 11:51:36:170::[3904] Main: Client updated
    2013/11/15 11:51:36:170::[3904] FFState::GetProperty: UpdatesDiscoveryPeriodStartTime = 13028839606153
    2013/11/15 11:51:36:170::[3904] FFState::GetProperty: firstrun =
    2013/11/15 11:51:36:170::[3904] FFState::GetProperty: productreleaseid = O365ProPlusRetail
    2013/11/15 11:51:36:170::[3904] ShellExec: C:\Program Files\Microsoft Office 15\ClientX86\integratedoffice.exe CUSTOMIZE RERUNMODE config "\\server\netlogon\office2013\officex86\configuration.xml" app root\office15\firstrun.exe admin=1
    2013/11/15 11:51:37:324::[3904] Products configured successfully


    • Edited by Visokoo Friday, November 15, 2013 8:07 PM
    Friday, November 15, 2013 8:05 PM
  • is there any existing Office installation on the client machine at all, prior to this script execution?

    (it seems a little conflicted, based on the symptoms you're having)


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Saturday, November 16, 2013 6:15 AM
  • Hey Don,

    There was an existing installation, but has been removed using the offscrub vb scripts. I've kind of given up on the ODT tool as for some installs, it always seems to freeze at 84% or 89%. Some installs go through smoothly, but the rest are stuck and MSFT has very poor documentation as to why it's like that. 

    Thank you so much for the information thus far and trying to help. I will mark your initial reply as the answer to my original question.


    • Edited by Visokoo Monday, November 25, 2013 4:43 PM
    Monday, November 25, 2013 4:43 PM