I have set up Office 2013 Home and Business on a network share using the Office Deployment Tool.

Domain members can install Office 2013 with no problems using the command line

\\Server\share\Office2013\setup.exe /configure \\Server\share\Office2013\configuration-home-and-biz.xml

However, if the PC is not a member of the domain I get an Access Denied message, even though "everyone" has full control of the share and NTFS files and subfolders

The full message is as follows,

Access denied to installation source

Sorry, we ran into a problem accessing a required file. Please check that the installation source has correct permissions, the try again.

Go online for additional help

Error Code: 5-4

As soon as I join the PC to the domain the installation works but I would like to pre-install Office as part of an MDT Task Sequence before the PC joins the domain.

Does anyone know how I can make this work?

The Office setup log shows a different error code

03/05/2014 16:23:24.834 SETUP (0xe38) 0xec0  Click-To-Run apx75 Monitorable TryLaunchClient::HandleStateAction: C2R Client returned failing error code 17002 

FYI: My config xml file contains the following

<Configuration>
  <Add SourcePath="\\Server\share\Office2013\" OfficeClientEdition="32" >
    <Product ID="HomeBusinessRetail">
      <Language ID="en-us" />
    </Product>
  </Add>
  <Updates Enabled="TRUE" UpdatePath="\\Server\share\Office2013\" />
  <Display Level="Full" AcceptEULA="TRUE" />
        <!--  <Display Level="None" AcceptEULA="TRUE" />  -->
  <Logging Name="OfficeSetup-*.txt" Path="%temp%" />
  <Property Name="AUTOACTIVATE" Value="0" />
</Configuration>

The content in Config.xml is ok and I think this is still a network access permission. If you create network installation point, please make sure that computers which didn't join domain always have access to a network source for the Office installation files.

We may directly access the network installation point from that computer and check whether we still receive the error message. And, turn off Antivirus/filewall programs on that machine to avoid the security programs' deny.

Thanks.

Tony Chen
TechNet Community Support

C2R editions of Office, during the installation routine, will initially commence execution in the security context of the logged in user, but partway through the installation routine the installation transitions into the security context of the local computer account. This means that unless the computer account also has network access permissions to the installation source folder/share, the installation routine will fail.
http://technet.microsoft.com/en-us/library/jj219423(v=office.15).aspx#PrepareDeploy

Important:

The computer account for the computer on which you install Click-to-Run for Office 365 products must have read permission to the network share that contains the Office Deployment Tool, the customized Configuration.xml file, and the Click-to-Run for Office 365 product and language files. If you cannot give read permission to the computer account, you can copy the files down to the computer from the network share, and then run Setup from the computer. After the installation is complete, you can delete those files from the computer. 

To workaround this, your installation script routine can copy the installation source files from the server folder/share to a local folder on the computer, then launch the setup routine from that local source.

In your example scenario, the workgroup computer (because it is not a member of "DOMAIN\Authenticated Users" does not have access permissions to the server folder/

Thanks, that's something I can look into on Monday.

I gave "Everyone" full access to the share & NTFS files, as well as "system", are you saying that doesn't include the local computer?

Is there a special account I can add that allows any non-domain computer or would I need to add it individually?

The script is run with domain admin rights, the local computer can browse/edit all of the files in the share

I gave "Everyone" full access to the share & NTFS files, as well as "system", are you saying that doesn't include the local computer?

Is there a special account I can add that allows any non-domain computer or would I need to add it individually?

"Everyone" includes domain objects. Your workgroup computer isn't a domain member, so it isn't included within that scope.

You *might* be able to enable the Guest account, to get this to work, but Guest is disabled by default since it's a significant security risk.

The script is run with domain admin rights, the local computer can browse/edit all of the files in the share

Well, if you are running the script with DomainAdmin rights (which is really a very scary thing to do), the DA account is the security context, and not that of the local computer.

In a domain, every domain member computer (computer which are domain-joined), has an account (e.g. if your computer is named THOMS-PC, the computer account would be THOMS-PC$ )

Computer accounts, and user accounts, both need to "logon", and usually both have "passwords".
The computer account/password is used, to establish the secure channel, and it is established automatically when the domain member computer starts up (the computer account logon occurs).
After this startup, the user then logs on, using the user account/password.
If there is a problem with the computer account/password, the secure channel isn't established, and typically the user won't be able to logon.

In a workgroup computer scenario (i.e. the computer is not domain-joined), there is no computer account in the domain, so the user accounts are in the local computer security database, and, any attempt to connect from there to a resource secured in the domain will result in a prompt/request/challenge for domain credentials. Because the computer's LocalSystem "account" cannot respond to a request for credentials, the authentication fails.

@DonPick The domain admin account was only used for narrowing down the permissions problem, it's not part of the live deployment plan!

I'm aware about a workgroup PCs relationship when accessing a domain but no other bit of software has ever complained before. 

Copying all the files over to the workgroup PC does work but it seems a very cumbersome way to do it. I guess that is another reason why it would have been better to get the more expensive VL MSI edition

I'm not going to be copying over the installation files to install Office, I'll just install Office after the client has joined the domain. 

As I need to activate each Office 2013 installation manually anyway (due to Home and Business edition activation awkwardness), that will be quicker than copying the files first

I'm aware about a workgroup PCs relationship when accessing a domain but no other bit of software has ever complained before

it's an odd behaviour, to be sure, and I've not come across it until O365 in C2R packaging format.

I just wanted to let any visitors know that I've got this all sorted so I can silently deploy Office 2013 Home & Business via MDT.

I wrote a rather lengthy article on my blog if you want to walkthrough the entire process - The MDT and Office 2013 Click-to-Run Jigsaw Puzzle http://wp.me/pLog8-iF

Hi,

You can try net use command before you run: Setup.exe /configure configuration.xml