SharePoint Server Subscription Edition (SPSE) kumulative Updates sind eine wiederkehrende Operations-Aufgabe, die jeder Farm-Administrator kennt: CU herunterladen, auf alle Server verteilen, Binaries in der richtigen Reihenfolge installieren, PSConfig ausführen, Daumen drücken. Der Prozess ist gut dokumentiert, aber mühsam, fehleranfällig und voller versteckter Fallstricke — besonders bei Multi-Server MinRole-Farmen und PowerShell Remoting.

In diesem Artikel zeige ich, wie ich GitHub Copilot (ein KI-Coding-Agent direkt in VS Code) verwendet habe, um ein End-to-End CU-Upgrade einer 4-Server SPSE-Farm zu planen, scripten, ausführen und überwachen — von Build 16.0.18526.20508 (KB5002768, Juli 2025) bis 16.0.19127.20442 (KB5002822, Januar 2026). Dabei sind wir auf echte Remoting-Probleme gestossen, die der Agent live in der Session diagnostiziert und autonom gelöst hat — ein solider Anwendungsfall für agentisches Infrastruktur-Management.

Die Farm-Topologie

SQL Backend: Zwei Instanzen (SQL-SRV-01\SQL-INST-01 und SQL-SRV-02\SQL-INST-02) mit ~61 Datenbanken über 8 Webanwendungen.

Der Operator-Rechner war SP-SRV-02 (der Application Server), auf dem VS Code mit GitHub Copilot lief.

Phase 0: Farm Discovery & Planung

Das Erste, was der Agent tat — bevor er eine einzige Zeile Script schrieb — war die Farm zu entdecken:

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
"

Aus dem Ergebnis leitete der Agent die Patch-Reihenfolge ab (Search → DistributedCache → Application → WebFrontEnd — die empfohlene MinRole-Reihenfolge für minimale Benutzer-Ausfallzeit), identifizierte die SQL-Instanzen, Content-Datenbanken, Webanwendungen und schrieb einen umfassenden Upgrade-Bericht — alles bevor er das Automationsscript generierte.

Kernaussage: Der Agent schrieb kein generisches Script. Er inspizierte die tatsächliche Farm-Topologie und passte seinen Output an die reale Infrastruktur an.

Phase 1: Das Automationsscript — Architektur

Der Agent produzierte ein einzelnes ~850-Zeilen PowerShell-Script (Install-SPSE-January2026CU.ps1) in 6 Phasen:

Phase 2: Das Remoting-Problem — Warum Start-Process in WinRM hängt

Hier begann der echte Spass. Als das Script Phase 4 erreichte — die CU-Binary auf dem ersten Remote-Server (SP-SRV-01) installieren — hing es endlos.

Der problematische Code:

# Das hängt wenn es in Invoke-Command läuft
Invoke-Command -ComputerName "SP-SRV-01" -ScriptBlock {
    Start-Process -FilePath "C:\SPPatches\uber-subscription-kb5002822-fullfile-x64-glb.exe" `
        -ArgumentList "/quiet /norestart" -Wait
}

Warum es hängt

Wenn man einen Prozess über WinRM (Invoke-Command) aufruft, läuft die Remote-Session in Session 0 — der nicht-interaktiven Services-Session. Start-Process -Wait erwartet, dass der Prozess sauber beendet wird, aber grosse MSI/EXE-Installer über WinRM erzeugen oft Kind-Prozesse, die den Elternprozess überleben, oder warten auf interaktive Session-Handles, die nie ankommen.

Die Lösung: Scheduled Tasks

Der Agent diagnostizierte dies anhand des Hänge-Verhaltens und schrieb die Remote-Install-Funktion um auf Windows Scheduled Tasks — die unter SYSTEM in ihrer eigenen Session laufen, unabhängig von 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
    # Polling alle 20 Sekunden...
} -ArgumentList $patchExe, $timeoutMin, $taskName

Warum das funktioniert: Der Scheduled Task läuft als SYSTEM mit RunLevel Highest — volle Admin-Rechte, keine WinRM-Session-Einschränkungen. Die WinRM-Session pollt nur den Task-Status.

Phase 3: Das Double-Hop-Problem — CIM/WMI als Alternative

Drei von vier Servern akzeptierten WinRM-Verbindungen — aber SP-SRV-02 (der lokale Application Server) verweigerte. Der Agent versuchte lokales Start-Process, Invoke-Command -ComputerName localhost, lokales schtasks — alles fehlgeschlagen.

Die Lösung: 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"
    }

Warum CIM funktionierte, wenn WinRM nicht ging: Das Operator-Konto hatte DCOM-Aktivierungsrechte auf SP-SRV-02 (via Group Policy), obwohl es keinen WinRM-Zugriff hatte. CIM über DCOM nutzt den RPC Endpoint Mapper (Port 135 + dynamische Ports) statt WinRM's HTTP-Port (5985/5986). Anderes Protokoll, andere ACLs.

Phase 4: Parallele Binary-Installation

Die initiale Installation war sequentiell. Bei einer 4-Server-Farm mit einem 1.6 GB CU dauert jede Binary-Installation 30–40 Minuten. Sequentiell = 2+ Stunden nur für Binaries.

Da Binary-Installationen keine SharePoint-Datenbanken oder -Dienste berühren (sie aktualisieren nur Dateien auf der Festplatte), gibt es keinen Grund, sie nicht parallel auszuführen. Der Agent startete alle 4 gleichzeitig:

• 3× Scheduled Tasks (WinRM-Server)
• 1× CIM/WMI Win32_Process.Create (lokaler Server)

Phase 5: Monitoring — CIM-basierte Prozessüberwachung

Mit 4 parallelen Installationen brauchten wir eine Monitoring-Lösung, die auf allen Servern funktioniert. CIM war die universelle Wahl:

$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 "  Keine Installer-Prozesse gefunden"
    }
}

Der Agent generierte einen robusten PSConfig-Befehl, der alle gängigen Fallstricke (wie hängende Dienste) berücksichtigt:

# PSConfig-Aufruf durch den Agenten
psconfig.exe -cmd setup -cmd upgrade -inplace b2b -wait -force -cmd applicationcontent -install -cmd installfeatures

Der Agent überwachte den Fortschrittsbalken in Echtzeit. Als der Upgrade auf SP-SRV-02 abgeschlossen war, wechselte er automatisch zu den restlichen Servern (SP-SRV-01, SP-SRV-03, SP-SRV-04) und führte dort den identischen Prozess durch. Das gesamte Datenbank-Schema wurde ohne manuelle Eingriffe auf Build 16.0.19127.20442 gehoben.

Fazit

Einen KI-Coding-Agent für SharePoint Server Patching einzusetzen bedeutet nicht nur Scripts zu generieren — es geht darum, einen Assistenten zu haben, der in Echtzeit beobachten, diagnostizieren und anpassen kann. Die drei grössten technischen Gewinne in dieser Session waren:

1. 1Den WinRM/Start-Process Hänger entdecken und auf Scheduled Tasks wechseln
2. 2Auf CIM/WMI zurückfallen als WinRM auf einem Server blockiert war
3. 3Automatisierter PSConfig-Ablauf nach paralleler Binary-Installation

Die totale Binary-Installationszeit für alle 4 Server (parallel) war etwa gleich wie das Patchen des langsamsten einzelnen Servers — der Application Server mit ~2 Stunden. Sequentiell wären es ~4 Stunden gewesen. Der Agent übernahm das Monitoring, führte PSConfig fehlerfrei durch und validierte die Farm-Gesundheit am Ende der Session.

Wenn Sie SharePoint Server SE Farmen verwalten, sind die Techniken in diesem Artikel (Scheduled Tasks für Remote-Installationen, CIM/WMI als Remoting-Fallback, automatisierte PSConfig-Orchestrierung) es wert, in Ihr Toolkit aufgenommen zu werden — unabhängig davon, ob Sie einen KI-Agent verwenden.

Sämtlicher Code in diesem Artikel wurde während einer Live-Agentic-Coding-Session in VS Code mit GitHub Copilot generiert und ausgeführt.