0

Thera are a lot of material about patching Windows using PowerShell. And some about patching remotely.
When optimizing/stabilizing patches for SharePoint they should be applied in separate batches.

  1. OS Patches
  2. SQL Patches
  3. SharePoint Patches

To greatly ease the selection of patches to apply, I'm using the module PS Gallery - PSWindowsUpdate.

However, most of the patches for SharePoint has to be run interactively, which is possible using Scheduled Tasks. But that normally requires a user with the appropriate permissions to already be logged in locally, which defies the purpose of remote scripting :/

But I remembered setting S4U, Service For User, that should bypass that requirement. However, I can't seem to find the correct params to use.

I do think S4U is blocked from accessing the network (although other sources states otherwise), so I have tried to make sure the patches are downloaded beforehand. Either by using the built-in WindowsUpdateProvider or PSWindowsUpdate.

The account used for running the scheduled task of course also need the system privilege Logon as batch job.

One thing that might trip things up in my case is that legacy RPC has to be kept disabled throughout the network.

Invoke-Command -ComputerName RemoteSrv -ScriptBlock {
  $SoftwareUpdates = Start-WUScan -SearchCriteria "Type='Software' AND IsInstalled =0"
  Install-WUUpdates -Updates $SoftwareUpdates -DownloadOnly $true | Out-Null

  $Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date).AddYears(10)

  $Argument = "Install-WindowsUpdate -NotCategory 'Microsoft SQL Server','Office Online Server' -AcceptAll -AutoReboot"

  $Action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "$Argument"

  $Principal = New-ScheduledTaskPrincipal `
    -UserId 'domain\userid' `
    -RunLevel Highest `
    -LogonType S4U

  Register-ScheduledTask `
    -TaskPath '\SharePoint\' -TaskName 'PatchSharePoint' `
    -Trigger $Trigger `
    -Principal $Principal `
    -Action $Action `
    -Force | Out-Null

  Start-ScheduledTask -TaskPath '\SharePoint\' -TaskName 'PatchSharePoint'
}

The patches requiring interactive logon still isn't applied. But the Action Completed in the Task Scheduler history states.

Task Scheduler successfully completed task "\SharePoint\PatchSharePoint", instance "{...},  
action "PowerShell.exe" with return code 0.

Edit: Fixed typo in Argument.

Dennis
  • 871
  • 9
  • 29
  • Instead of trying to start the task remotely, schedule it to run a minute or two in the future. Iirc, you can kick those off remotely due to a security design – Doug Maurer Feb 27 '23 at 22:40
  • https://stackoverflow.com/questions/48343993/batch-file-from-scheduled-task-returns-code-2147942401 – rinat gadeev Feb 28 '23 at 06:41
  • @DougMaurer And that is what I'm doing as far as I can tell. – Dennis Feb 28 '23 at 07:42
  • @rinatgadeev I've already got `logon as batch job` privileges. – Dennis Feb 28 '23 at 07:43
  • Using [JEA](https://stackoverflow.com/questions/7078958/powershell-remote-microsoft-update-session-access-denied-0x80070005/60046097#60046097) actually took me a little further down the road. – Dennis Feb 28 '23 at 12:15
  • Using JEA remote seems to trigger the double-hop issue. – Dennis Feb 28 '23 at 13:16
  • You see that command called start scheduled task? That is you trying to start the task remotely. I’m saying schedule it to run on its own in the future. Do NOT start it yourself, that’s my suggestion. – Doug Maurer Feb 28 '23 at 14:21
  • @DougMaurer No. The process scheduled do start, se simplified example below. – Dennis Feb 28 '23 at 14:30
  • All your examples i see contain start-scheduledtask. If you don’t want to try the suggestion, that’s fine. Take care. – Doug Maurer Feb 28 '23 at 17:28
  • Yes, and that is done within the remote session as in "locally". You can very easy verify the effect by simply running the simple example is the answer below your self :) – Dennis Feb 28 '23 at 19:07
  • You’re not understanding. You are still executing that local command remotely. And as I stated, I recall that being blocked by a security design. Hence I suggested you just try letting it start itself. This is specific to pswindowsupdate module – Doug Maurer Mar 01 '23 at 22:17

2 Answers2

0

Ok, there is actually no issue with starting tasks requiring interactive sessions using Scheduled Tasks, S4U.

This example works just fine...

Invoke-Command -ComputerName RemoteSrv -ScriptBlock {

  $Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date).AddYears(10)

  $Argument = "mmc.exe"

  $Action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "$Argument"

  $Principal = New-ScheduledTaskPrincipal `
    -UserId 'domain\userid' `
    -RunLevel Highest `
    -LogonType S4U

  Register-ScheduledTask `
    -TaskPath '\PoC\' -TaskName 'StarMMC' `
    -Trigger $Trigger `
    -Principal $Principal `
    -Action $Action `
    -Force | Out-Null

  Start-ScheduledTask -TaskPath '\PoC\' -TaskName 'StartMMC'
}

The MMC won't be run interactive with the desktop of the user of course. That was never the intention. But it will start.

I don't even need a scheduled task. This will also start a process that requires Interactive privileges.

Enter-PSSession RemoteSrv
[RemoteSrv] mmc.exe

Or I'm I missing something?

Dennis
  • 871
  • 9
  • 29
0

Most of the solutions I've found for patching SharePoint remotely is based on PSExec or direct downloads of the CU, instead of using WUAU, such as GitHub - SharePoint Patchify.

Dennis
  • 871
  • 9
  • 29