VBO Wiki

3. WSUS Force Check-In

7 min read

RU | EN | DE

Step 1. Prepare the script

Create a file: Force-WSUSCheckIn.ps1

The contents are:

[CmdletBinding()]  
param()  
  
$ErrorActionPreference = 'Stop'  
  
$LogDir = 'C:\ProgramData\WSUS'  
$LogFile = Join-Path $LogDir 'Force-WSUSCheckIn.log'  
  
if (-not (Test-Path $LogDir)) {  
    New-Item -Path $LogDir -ItemType Directory -Force | Out-Null  
}  
  
function Write-Log {  
    param(  
        [string]$Message,  
        [string]$Level = 'INFO'  
    )  
  
    $line = '{0} [{1}] {2}' -f (Get-Date -Format 'yyyy-MM-dd HH:mm:ss'), $Level, $Message  
    Add-Content -Path $LogFile -Value $line  
    Write-Output $line  
}  
  
try {  
    Write-Log '--- Start WSUS trigger ---'  
  
    try {  
        $wua = Get-Service -Name wuauserv -ErrorAction Stop  
        if ($wua.Status -ne 'Running') {  
            Write-Log 'Starting service wuauserv'  
            Start-Service -Name wuauserv -ErrorAction Stop  
            Start-Sleep -Seconds 3  
        }  
        else {  
            Write-Log 'Service wuauserv already running'  
        }  
    }  
    catch {  
        Write-Log "Could not verify/start wuauserv: $($_.Exception.Message)" 'WARN'  
    }  
  
    Write-Log 'Creating Microsoft.Update.Session COM object'  
    $updateSession = New-Object -ComObject Microsoft.Update.Session  
  
    Write-Log 'Running update search'  
    $searchResult = $updateSession.CreateUpdateSearcher().Search("( IsInstalled = 0 and IsHidden = 0 )")  
  
    if ($null -ne $searchResult -and $null -ne $searchResult.Updates) {  
        Write-Log ("Search completed successfully. Updates found: {0}" -f $searchResult.Updates.Count)  
    }  
    else {  
        Write-Log 'Search completed, but result object is empty' 'WARN'  
    }  
  
    Write-Log '--- Finish WSUS trigger OK ---'  
    exit 0  
}  
catch {  
    Write-Log ("ERROR: {0}" -f $_.Exception.Message) 'ERROR'  
    Write-Log '--- Finish WSUS trigger FAILED ---' 'ERROR'  
    exit 1  
}

Step 2. Put the script in an accessible place

The easiest way is in SYSVOL, so that all servers in the domain can conveniently read the file.

For example: \\domain.local\SYSVOL\domain.local\scripts\WSUS\Force-WSUSCheckIn.ps1

If there is no WSUS folder, create it.

Important:

  • domain computers must have Read to this path
  • you usually don’t need to change permissions; for SYSVOL it usually already works as it should

Step 3. Create a security group for problematic servers

IN ADUC: dsa.msc

Next:

  • open the container where you store groups, for example Groups
  • Rechtsklick → Neu → Gruppe
  • Name: GG_WSUS_ProblemServers
  • Type: Sicherheit
  • Bereich: Global
  • OK

Then add 20 servers to it:

  • open group properties
  • Mitglieder tab
  • Hinzufügen
  • add server computer objects This is a safe way to restrict the use of GPOs without changing the OU structure. Security filtering allows you to apply a GPO only to members of a specified group.

Step 4: Create a new GPO

Open: gpmc.msc

Next:

  • open:
    • Forest: rrlnz.local
    • Domains
    • rrlnz.local

Now there are two options where to link the GPO:

Option A is the easiest

Link to the domain itself:

  • Rechtsklick on domain.local
  • Create a GPO in this domain, and Link it here…

Name, for example:
GPO_WSUS_ForceCheckIn_ProblemServers

This will work if the servers are scattered across different OUs, and you want one management point. We will then limit the use of security filtering. GPO scope is defined by a reference to site/domain/OU, and the actual application can be further limited by filtering and targeting.

Option B - if there is a common top OU

You can link higher up the tree, but it is not necessary.

Step 5. Setting up Security Filtering

Select the created GPO in GPMC.

On the Scope tab:

In the Security Filtering block

  • remove Authenticated Users
  • add the group GG_WSUS_ProblemServers

After this, the GPO will only apply to servers from this group, even if the link is at the domain level. This is exactly the standard security filtering scenario for GPOs.

Important

Check on the Delegation → Advanced tab that the GG_WSUS_ProblemServers group has the rights:

  • Read
  • Apply group policy

Usually, when added correctly through Security Filtering, this is set as needed.

Step 6: Edit the GPO

Rechtsklick on GPO → Bearbeiten The Gruppenrichtlinienverwaltungs-Editor opens.

Step 7. Add file copying via Preferences → Files

Go here: Computerkonfiguration -> Einstellungen -> Windows-Einstellungen -> Dateien If you have English equipment, it will be: Computer Configuration -> Preferences -> Windows Settings -> Files

Now:

  • Rechtsklick → Neu → Datei

Fill in:

Allgemein

  • Action: Aktualisieren
  • Quelldate:
    \\rrlnz.local\SYSVOL\rrlnz.local\scripts\WSUS\Force-WSUSCheckIn.ps1
  • Zieldatei:
    C:\ProgramData\WSUS\Force-WSUSCheckIn.ps1

Why Aktualisieren and not Ersetzen:

  • Update is usually sufficient and softer when accompanied
  • the file will be updated when the GPO preference item changes Preferences node and Files item are used precisely for such additional settings and file deployment.

Step 8. Add Scheduled Task via Preferences

Go here: Computerkonfiguration -> Einstellungen -> Systemsteuerungseinstellungen -> Geplante Tasks

In English: Computer Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks

Now:

  • Rechtsklick → Neu
  • select Geplanter Task (mindestens Windows 7)
    or a similar option for the new OS

Allgemein tab

Fill in like this:

  • Action: Erstellen
  • Name: Force-WSUS-CheckIn
  • Beschreibung:
    Runs Microsoft.Update.Session search to force WSUS check-in on problematic servers
  • Ausführen als / Sicherheitsoptionen:
    NT AUTHORITY\SYSTEM
  • enable:
    • Unabhängig von der Benutzeranmeldung ausführen
    • Mit höchsten Privilegien ausführen Running from SYSTEM for a computer task is more correct here than from a domain administrator.

Trigger Tab

Add two triggers.

Trigger 1

  • Neu
  • Aufgabe starten: Beim Start
  • Verzögern für: 20 Minuten

Trigger 2

  • Neu
  • Aufgabe starten: Nach Zeitplan
  • Einstellung: Täglich
  • Start: 03:15:00
  • if the delay field is available:
  • Verzögern für: 1 Stunde
  • enable Activiert

The idea here is simple: one launch after the server starts and one scheduled launch per day. This does not conflict with normal Group Policy processing and does not create overly aggressive noise. Computer GPOs are applied at startup and then updated periodically in the background.

Aktionen tab

Add one action:

  • Program/Skript:
    powershell.exe
  • Argumente hinzufügen: -NoProfile -ExecutionPolicy Bypass -File “C:\ProgramData\WSUS\Force-WSUSCheckIn.ps1”
  • Start in: C:\ProgramData\WSUS ###Bedingungen tab

I would remove too strict restrictions:

  • remove the dependency on Netzstrom, if these are servers in a VM and the field exists at all
  • don’t get stuck on Idle

Einstellungen tab

Put:

  • Aufgabe kann bei Bedarf ausgeführt werden
  • Aufgabe so schnell wie möglich nach einem verpassten Start ausführen
  • Wenn die Aufgabe bereits ausgeführt wird → Keine neue Instanz starten Group Policy Preferences support Scheduled Tasks and item-level targeting for preference items if you need to further narrow the application of individual elements.

Step 9. Is it still necessary to do Item-level targeting?

Not necessary if you are already using Security Filtering through the GG_WSUS_ProblemServers group.

But if you want “double insurance”, you can enable targeting for both preference items - both File and Scheduled Task.

How to enable

Open item → Gemeinsam / Common tab

  • check the box Elementbezogene Zielgruppenadressierung
  • press Zielgruppenadressierung…

There you can add:

  • Security Group
  • and specify GG_WSUS_ProblemServers Or even specific computer names. Microsoft explicitly states that item-level targeting allows you to make individual preference items apply only to selected computers within a single GPO.

My advice

Do this:

  • Security Filtering at GPO level
  • and without item-level targeting on the first pass

It’s easier.
If you then see that you need more, add targeting.

Step 10. Force the application on one test server

On one problematic server, run:

gpupdate /force

Then restart the server or at least check if the task appears.

Why a reboot is useful: computer GPO settings are applied when the machine starts, and Scheduled Task as a computer preference is often more convenient to validate after the normal startup cycle.

Step 11. Check that the GPO actually arrived

Option 1 - gpresult

On the server:

gpresult /h C:\Temp\gpresult.html Open the file C:\Temp\gpresult.html and check:

  • Applied GPOs
  • is there GPO_WSUS_ForceCheckIn_ProblemServers there?

Microsoft documents gpresult as the standard way to see resulting policies.

Option 2 - Group Policy Results Wizard

To GPMC:

  • Group Policy Results
  • Group Policy Results Wizard
  • select the desired server

This is also the official way to see actually applied GPOs.

Option 3 - logs

If the GPO did not arrive, look:

  • Event Viewer
  • Applications and Services Logs -> Microsoft -> Windows -> GroupPolicy -> Operational

Microsoft recommends this log for troubleshooting GPO implementations. If the problem is with Preferences, their events are written to the Application log, and additional detail can be enabled via Group Policy logging/tracing.

Step 12. Check the task and script log

On the server: Get-ScheduledTask -TaskName “Force-WSUS-CheckIn”
Get-ScheduledTaskInfo -TaskName “Force-WSUS-CheckIn”

Then look at the log:

Get-Content C:\ProgramData\WSUS\Force-WSUSCheckIn.log -Tail 50

If you want to start it manually right away:

Start-ScheduledTask -TaskName “Force-WSUS-CheckIn”

Step 13. After checking - distribute to all 20

When one server worked:

  • make sure the file is copied
  • the task is created
  • log is written
  • WSUS is updated

Then just wait for the Group Policy update on the remaining servers or make a selective gpupdate /force.

Backlinks