Unable to install SharePoint 2016 patches via Remote PowerShell with Windows Update

Question

I am trying to install a patch to SharePoint 2016 Farm using Remote PowerShell. I have administrator rights on the remote SharePoint machines and Windows Update COM Objects are created successfully as well. But, as soon as the Install starts for the patch, the Windows Update Agent terminates the installation with the following log in SoftwareDistribution\ReportingEvents.log -

http://pasted.co/24945c2d

If I try running my script with a different KB number which is not related to SharePoint, the patch gets installed successfully.

On checking the API reference for the error code, it says the following -

0x80240020 WU_E_NO_INTERACTIVE_USER Operation did not complete because there is no logged-on interactive user.

I searched around and found an exact thread over here - https://batchpatch.com/forum/topic/new-user-getting-hresult-2145124320

Is there any way to install the SharePoint patch without logging into the SharePoint Farm with RDP and then manually installing the updates?

EDIT - Is it possible not to use CredSSP? I don't want to use CredSSP solution. The problem with CredSSP is that it uses Clear Text which poses a security risk. Furthermore, if a single machine is compromised, it could lead to compromise of other machines as well.

Answer 1

Yes, you can install it remotely. Trevor wrote a nice script, You can get the script from the ARSPPM repo on GitHub.

here is example, how u run this.

Import-Module .\ARSPPM.psm1
$cred = Get-Credential #must be a Local/Farm Admin on SharePoint
$ph = SP01 #This is the host where farm detection takes place, as well as where Content Databases are upgraded  

$patch = "\\fileserver\patches\ubersrvprj2013-kb3114493-fullfile-x64-glb.exe" #UNC to the patch    

Start-RmSPUpdate -StopServices $true -PauseSearch $true -PrimaryHost $ph -ConcurrentPatching $false -Cred $cred -PatchToApply $patch

There are currently a few limitations. You must be in the same directory as where ARSPPM.psm1 is located due to some hard coded pathing (we have to load the module into PowerShell jobs which requires the path).