The system account can work just fine if you've granted the proper permissions to the location of the files (both and NTFS). The system account uses the computer account of the system it is on to perform network tasks and all computer accounts of systems in a domain are part of the built-in dynamic group Domain Computers. Thus, just add this group as having read permissions on the location you are specifying. Of course, hard-coding a location like this doesn't help much if you have multiple locations - that's the whole point of having DPs. If you have just a single location or all of your locations are very well connected, then this isn't an issue - you're very much in the minority though. If all of your systems are well connected though, then downloading the Office source files again shouldn't be an issue in the first place though.
J From: [email protected] [mailto:[email protected]] On Behalf Of Bradley, Matt Sent: Wednesday, January 13, 2016 4:10 PM To: [email protected] Subject: [mssms] Running batch file against a share Since the application model does not have the ability to run directly from a distribution point, I thought about creating an application that runs a batch file to install from the SCCM share. It doesn't seem to work, though. I read elsewhere the system account doesn't behave well in these scenarios. Any thoughts on what I might could do more successfully? I'm trying add Skype to our existing Office 2013 install. Running a config file with the setup.exe produces the desired install. I'm just trying to keep from deploying the entire Office 2013 suite to install just one app. I could do it from a package, and choose to run from the distribution point, but that would leave me with no detection clause.
