SharePoint Server Subscription Edition (SPSE) cumulative updates are a recurring operations task that every farm admin knows well: download the CU, distribute it across servers, install binaries in the right order, run PSConfig, cross your fingers. The process is well-documented but tedious, error-prone, and full of hidden pitfalls — especially when you're working with multi-server MinRole farms and PowerShell Remoting.

In this article I'll walk through how I used GitHub Copilot (an AI coding agent running directly inside VS Code) to plan, script, execute, and monitor an end-to-end CU upgrade of a 4-server SPSE farm — from build 16.0.18526.20508 (KB5002768, July 2025) all the way to 16.0.19127.20442 (KB5002822, January 2026). Along the way, we ran into real-world remoting issues that the agent diagnosed and fixed autonomously in the live session — making this a solid case study for agentic-driven infrastructure work.

The Farm Topology

SQL Backend: Two instances (SQL-SRV-01\SQL-INST-01 and SQL-SRV-02\SQL-INST-02) hosting ~61 databases across 8 web applications.

The operator's machine was SP-SRV-02 (the Application server), running VS Code with GitHub Copilot.

Phase 0: Farm Discovery & Planning

The first thing the agent did — before writing a single line of script — was discover the farm:

powershell.exe -NoProfile -Command "
    Add-PSSnapin Microsoft.SharePoint.PowerShell
    Get-SPFarm | Select-Object Name, BuildVersion
    Get-SPServer | Where-Object { $_.Role -ne 'Invalid' } |
        Select-Object Name, Role, Status | Format-Table -AutoSize
"

From this, the agent mapped out the patching order (Search → DistributedCache → Application → WebFrontEnd — the recommended MinRole order for minimal user-facing downtime), identified the SQL instances, content databases, web applications, and wrote a comprehensive upgrade report — all before generating the automation script.

Key takeaway: The agent didn't just write a generic script. It inspected the actual farm topology and tailored its output to the real infrastructure. It knew which server was local, which needed remoting, and which services needed special handling (Distributed Cache graceful shutdown, search pause).

Phase 1: The Automation Script — Architecture

The agent produced a single ~850-line PowerShell script (Install-SPSE-January2026CU.ps1) organized into 6 phases:

Phase 2: The Remoting Problem — Why Start-Process Hangs in WinRM

Here's where the real-world fun began. When the script reached Phase 4 — installing the CU binary on the first remote server (SP-SRV-01) — it hung indefinitely.

The code that broke:

# This hangs when running inside Invoke-Command
Invoke-Command -ComputerName "SP-SRV-01" -ScriptBlock {
    Start-Process -FilePath "C:\SPPatches\uber-subscription-kb5002822-fullfile-x64-glb.exe" `
        -ArgumentList "/quiet /norestart" -Wait
}

Why it hangs

When you invoke a process through WinRM (Invoke-Command), the remote session runs in Session 0 — the non-interactive services session. Start-Process -Wait expects the process to exit cleanly, but large MSI/EXE installers spawned through WinRM often create child processes that outlive the parent, or wait for interactive session handles that never arrive.

The Fix: Scheduled Tasks

The agent diagnosed this from the hang behavior and rewrote the remote install function to use Windows Scheduled Tasks — which run under SYSTEM in their own session, independent of WinRM:

Invoke-Command -ComputerName $ServerName -ScriptBlock {
    param([string]$ExePath, [int]$TimeoutMin, [string]$TaskName)
    Unregister-ScheduledTask -TaskName $TaskName -Confirm:$false -ErrorAction SilentlyContinue
    $action   = New-ScheduledTaskAction -Execute $ExePath -Argument "/quiet /norestart"
    $settings = New-ScheduledTaskSettingsSet `
        -ExecutionTimeLimit (New-TimeSpan -Minutes $TimeoutMin)
    Register-ScheduledTask -TaskName $TaskName -Action $action `
        -Settings $settings -User "SYSTEM" -RunLevel Highest -Force | Out-Null
    Start-ScheduledTask -TaskName $TaskName
    # Poll every 20 seconds...
} -ArgumentList $patchExe, $timeoutMin, $taskName

Why this works: The Scheduled Task runs as SYSTEM with RunLevel Highest — full admin rights, no WinRM session constraints. The WinRM session only polls the task state.

Phase 3: The Double-Hop — CIM/WMI as Alternative

Three of the four servers accepted WinRM connections — but SP-SRV-02 (the local Application server) refused. The agent tried local Start-Process, Invoke-Command -ComputerName localhost, local schtasks — all failed.

The Fix: CIM/WMI Process Creation

Invoke-CimMethod -ComputerName "SP-SRV-02" `
    -ClassName Win32_Process `
    -MethodName Create `
    -Arguments @{
        CommandLine = "C:\SPPatches\KB5002822\uber-subscription-kb5002822-fullfile-x64-glb.exe /quiet /norestart"
    }

Why CIM worked when WinRM didn't: The operator account had DCOM activation permissions on SP-SRV-02 (granted through group policy) even though it lacked WinRM access. CIM over DCOM uses the RPC endpoint mapper (port 135 + dynamic ports) instead of WinRM's HTTP port (5985/5986). Different protocol, different ACLs.

Phase 4: Parallel Binary Installs

The initial script installed servers sequentially. On a 4-server farm with a 1.6 GB CU, each binary install takes 30–40 minutes. Sequential = 2+ hours just for binaries.

Since binary installs don't touch SharePoint databases or services (they only update files on disk), there's no reason not to run them in parallel. The agent launched all 4 simultaneously:

• 3× Scheduled Tasks (WinRM servers)
• 1× CIM/WMI Win32_Process.Create (local server)

Phase 5: Monitoring — CIM-Based Process Watch

With 4 parallel installs running, we needed a monitoring solution that worked across all servers. CIM was the universal choice:

$servers = @('SP-SRV-01','SP-SRV-02','SP-SRV-03','SP-SRV-04')
foreach ($srv in $servers) {
    $procs = Get-CimInstance -ComputerName $srv -ClassName Win32_Process `
        -Filter "Name LIKE '%uber%' OR Name='msiexec.exe'"
    if ($procs) {
        foreach ($p in $procs) { Write-Host "  PID=$($p.ProcessId) Name=$($p.Name)" }
    } else {
        Write-Host "  No installer processes found"
    }
}

The agent generated a robust PSConfig command that handles common pitfalls like hanging services:

# PSConfig command executed by the agent
psconfig.exe -cmd setup -cmd upgrade -inplace b2b -wait -force -cmd applicationcontent -install -cmd installfeatures

The agent monitored the progress in real-time. Once the upgrade on SP-SRV-02 was complete, it automatically moved to the remaining servers (SP-SRV-01, SP-SRV-03, SP-SRV-04) to perform the same process. The entire database schema was upgraded to build 16.0.19127.20442 without manual intervention.

Conclusion

Using an AI coding agent for SharePoint Server patching isn't just about generating scripts — it's about having an assistant that can observe, diagnose, and adapt in real time. The three biggest technical wins in this session were:

1. 1Discovering the WinRM/Start-Process hang and switching to Scheduled Tasks
2. 2Falling back to CIM/WMI when WinRM was blocked on one server
3. 3Automated PSConfig orchestration after parallel binary installs

The total binary install time for all 4 servers (running in parallel) was roughly the same as patching the single slowest server — the Application server at ~2 hours. Sequential would have been ~4 hours. The agent handled monitoring, executed PSConfig flawlessly, and validated the overall farm health at the end of the session.

If you're managing SharePoint Server SE farms, the techniques in this article (Scheduled Tasks for remote installs, CIM/WMI as a remoting fallback, automated PSConfig orchestration) are worth adding to your toolkit regardless of whether you use an AI agent to drive them.

All code in this article was generated and executed during a live agentic coding session in VS Code with GitHub Copilot.