Exit Code 5: Access Denied

[ttunks]

I’ve been using BP to update our Windows devices to the newest version of Windows 10. From version 1709 to 1803. I have BP installed on one of our network servers. I create a new BP deployment using the latest Windows 10 1803 iso, add the hosts I want to upgrade, and set the BP task scheduler to run the deployment.

This method works flawlessly for 95% of our devices. The few devices this doesn’t work for, I receive an “Exit Code 5: Access Denied” message a few minutes after my task scheduler deployment starts.

From what I can tell, there is now difference from a device where BP works and from one that does not. All devices are included in our Domains Group Policy and connected to our network at the time of the set deployment time.

Any help would be appreciated.

[doug]

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

This error message is due to an issue with account permissions. The following link explains everything you need to know about authentication problems: BatchPatch Authentication in Domain and Workgroup (non-domain) Environments

If you are still stuck the BatchPatch Troubleshooting Guide can help you step through to figure out where things are going wrong.

[ttunks]

Thanks! I try your suggestions and let you know if I have any more issues.

[bweddell]

I’ve tried to do a batchpatch deployment of individual .msu files and also show this error. I’m using the same domain account that has domain admin privs in the domain. I can test connectivity \\servername\c$ and ability to creates files and directories from the server I’m running batchpatch from to computers I want to deploy to.

I’ve also read that exit code 5 comes from wusa directly (confirmed by running psexec in a command prompt).

In my case I am running Windows 10 with batchpatch 2020.9.25.16.33.

From other things I’ve seen on the Internet, this is by design since wusa isn’t allowed to perform remote execution. Is that correct?

If it is, what is the suggested mitigation from the batchpatch perspective since a deployment prefaces the command with wusa?

Although I’ve not tested it, I assume that may be a combination of (in batchpatch) to copy file/folder followed up by Execute remote process/command.

[doug]

@bweddell – .msu files can be installed remotely by BatchPatch. We do it all the time, and we have numerous tutorials posted on our website that demonstrate how to create a deployment for .msu files. It’s unclear to me what could be causing you to get an exit code 5 for your .msu deployment. I would suggest trying to install the .msu manually at the command prompt of the desired computer. Then see if it spits out a more useful error text that explains why it won’t install. Most likely if you can’t install it with BP, then it will also fail to install when you try to deploy it manually at the command prompt without using BatchPatch. It could be something like the .msu file that you are trying to deploy to the target is not compatible with the OS version or architecture.

[NotABot]

I too had been having the same issues as bweddell. The account I was logged into while running BP was an admin on that system as well as on the remote system trying to run the wusa.exe. Access was always denied. I’ve done reg changes in the past with no issues. I even tried to wrap the wusa.exe blahblah.msu into a .cmd file and try to run it that way.

Fortunately, I found a way to make it work. In the Remote Execution global settings within BP, I changed the Deployment context from Elevated token to SYSTEM. After I made that change, I was then able to deploy .msu’s!

Hope this helps.

[doug]

@NotABot – Thanks for sharing. What this problem occurring for *all* .msu files or just a particular one?

[NotABot]

I don’t know. I was only attempting to send out the remove Flash .msu. This was the first time I tried deploying .msu’s via BP.

Sorry…

[doug]

No problem. Thanks.

[Author]

Posts