I am deploying Office 2021 with SCCM.
The Office files are located in a remote share.
If I install with my user, there is no problem.
When deploying with SCCM with system, I get the following:
Line 204 contains the command line to the remote share.
I have tried adding the server name to the root of the share and gave it modify permissions.
Any idea to which user I need to give permissions in order it to work?
<![LOG[[Installation] :: Error Record:
-------------
Message : Function failed, setting exit code to [60002]. Access is denied
InnerException :
FullyQualifiedErrorId : Function failed, setting exit code to [60002]. Access is denied
ScriptStackTrace : at Execute-Process<Process>, C:\Windows\ccmcache\2a\AppDeployToolkit\AppDeployToolkitMain.ps1:
line 4513
at <ScriptBlock>, C:\Windows\ccmcache\2a\Office2021-64bit.ps1: line 204
at <ScriptBlock>, <No file>: line 1
at <ScriptBlock>, <No file>: line 1
PositionMessage : At C:\Windows\ccmcache\2a\AppDeployToolkit\AppDeployToolkitMain.ps1:4513 char:21
+ ... Throw "Function failed, setting exit code to [$returnCode ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If SCCM is installing, it’s using the Target Computer’s Computer Account in AD.
Make sure the Computer Account in AD has READ permissions to that remote share holding the files. By default, it has none. This is why most people use the SCCM cache for most apps.
I checked with process monitor, which user is installing the command while using SCCM, its “NT Authority\SYSTEM”
I have add the computer name of the SCCM server to the share and gave it FULL Control, but still its failing.
I think I don’t have a choice and copy the installation files into the package itself.
NTFS Security and Share permissions to allow to read the entire structure for builtin group Authenticated Users and if you want regular users not to access (even for reading) block Share permissions to builtin group Domain Users.
Each JOINED computer has a computer account in AD.
On each computer, there is a “NT Authority\SYSTEM” built-in account.
“NT Authority\SYSTEM” on your SCCM Server is a different account Computer account in AD than the one you are trying to install Office on.
May I suggest:
Create a security group in AD (e.g. Give ReadAccessToRemoteShare)
Give that security group read permissions to the folders on that remote share
You may have to give that security group permission to access the remote share too is you have changes the defaults permissions.
Add all the computer accounts of the computers that you want to install Office using the Remote Share. The SCCM server’s Computer does not need to be in there unless you want to install Office on it too.
Thank you for your suggestions, but i am working in a big Bank with a lot of workstations, i am sceptical that i will be allowed to add all those computer accounts into the share.
regarding LFM8787 suggestion…I do not see any share tab, only security, need to check why is that.
Thank you so much for taking the time to answer.
Amir
Usually it is not a security issue to give Computer accounts Read permissions to files but it is up to you. There is just no other way to make the SYSTEM accounts on computer able to read files on a remote computer share.
Instead of using the Remote Share you could make SCCM cache the entire 3GB of Office files locally. Then the SYSTEM account would have full permissions to the files during installation.
Authenticated Users includes all users and all computers. By giving Read permissions to Authenticated Users, you’re giving permissions to not only all your users, but also all your computers (each computer’s NT Authority\SYSTEM account can now read the share).
Now…having said that, I’m in agreement with T-A-G. I usually put all my install files in the SCCM share, regardless of the deployment method (GPO or other). The SCCM dir is already shared to all relevant entities, so I figure, “Why add another layer of complexity?”
A group that includes all users and computers with identities that have been authenticated. Authenticated Users doesn’t include Guest even if the Guest account has a password.