ConfigMgr 2012: How to Deploy Windows Updates as Available Without Forced Installation


10 views

In enterprise environments requiring strict change control (like financial or healthcare systems), we often need to make updates available without forcing installations. The default ConfigMgr 2012 behavior where updates automatically install at deadline can disrupt operations when:

  • Server reboots require change board approval
  • Critical systems have specific maintenance windows
  • Compliance mandates manual installation verification

Your current setup appears correct at first glance:

// Sample ADR properties that SHOULD prevent auto-installation
New-CMSoftwareUpdateAutoDeploymentRule -Name "CriticalUpdates" 
    -DeploymentTemplateName "ManualInstallTemplate" 
    -EnableDeployment $true 
    -UserNotificationOption DisplayAll 
    -SoftwareInstallation $false   // Critical setting
    -RestartServer $false          // Critical setting
    -NoInstallOnRemote $true

Yet the updates still forcibly install. Let's examine why.

In ConfigMgr 2012, two factors override your settings:

  1. The "As soon as possible" deadline creates an immediate effective deadline
  2. The client interprets available updates differently based on deployment type

Here's the proper configuration sequence:

1. Create ADR with these key settings:
   - Deployment Schedule: "As soon as possible" 
   - User Experience:
     * [ ] Software Installation: Unchecked
     * [ ] System Restart: Unchecked
     * User Notification: "Show in Software Center and show all notifications"

2. In the Deployment Template:
   - Purpose: "Available"
   - Deadline: [Not configured]
   - User Experience: "Users can run independently of assignments"

3. Client Settings Policy:
   - Computer Agent > Deadline randomization: Disabled
   - Software Updates > Enable installation deadline randomization: No

Check these registry values match your intent:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
   - DeadlineGracePeriodEnabled = 0
   - AutoInstallMinorUpdates = 0
   - ScheduledInstallTime = [blank]

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Mobile Client\Software Distribution
   - DeadlineBehavior = 0 (0x0)

For true WSUS-like behavior without any automatic deployment:

# PowerShell to create manual-only update group
$UpdateList = Get-CMSoftwareUpdate -Fast -IsExpired $false | Where {$_.ArticleID -eq "KB5005565"}
New-CMSoftwareUpdateGroup -Name "ManualApprovalGroup" -Update $UpdateList
Start-CMContentDistribution -SoftwareUpdateGroupName "ManualApprovalGroup" -DistributionPointName "DP01"

This makes updates available in Software Center without creating an actual deployment.

Before rolling out to production:

  1. Create a test collection with 2-3 non-critical servers
  2. Use the following WMI query to verify intended behavior:
    SELECT * FROM CCM_SoftwareUpdate WHERE EvaluationState != 0
  3. Monitor wuahandler.log for unexpected installation attempts
  • Never combine "Available" deployments with mandatory maintenance windows
  • Client policy refresh cycles may delay settings changes (typically 60 minutes)
  • Software Center caching can sometimes show incorrect installation options

When dealing with highly regulated server environments where reboots require change management approval, the standard ConfigMgr automatic deployment behavior becomes problematic. The requirement is essentially:

  • Auto-download and distribute critical patches (WSUS-style)
  • Make updates available in Software Center
  • Prevent automatic installation until manual trigger
  • Absolutely block unauthorized reboots

The key misunderstanding lies in how ConfigMgr interprets "as soon as possible" deadlines combined with your suppression settings. Even with:

Set-CMSoftwareUpdateDeployment -Name "Critical Patches" -DeploymentType Available -UserNotification DisplayAll -DeadlineBehavior NoAction -RestartBehavior NoRestart

The system still processes this as an enforced deployment due to fundamental differences between "Available" and "Required" deployment types in the 2012 architecture.

This PowerShell snippet creates the correct deployment type:


$UpdateCollection = Get-CMDeviceCollection -Name "All Servers"
$UpdateGroup = Get-CMSoftwareUpdateGroup -Name "2023-Q4 Critical"
$Schedule = New-CMSchedule -Start "01/01/2023 00:00" -NonRecurring

New-CMSoftwareUpdateDeployment 
    -SoftwareUpdateGroup $UpdateGroup 
    -Collection $UpdateCollection 
    -DeploymentType Available 
    -UserNotification DisplayAll 
    -PersistOnWriteFilterDevice $false 
    -SendWakeUpPacket $false 
    -VerbosityLevel OnlySuccessAndErrorMessages 
    -Schedule $Schedule 
    -OverrideServiceWindow $false 
    -RebootOutsideServiceWindow $false 
    -UseBranchCache $true
Setting Value Reason
Deployment Type Available Makes updates visible but not enforced
Deadline None Prevents automatic installation
User Experience Display in Software Center... Allows manual installation
Restart suppression Checked Blocks unauthorized reboots

Even with correct deployment settings, maintenance windows can override your intentions. Always verify with:

Get-CMMaintenanceWindow -CollectionId SMS00001 | Select Name, ServiceWindowType, IsEnabled

For this scenario, either:

  • Remove all maintenance windows from target collections
  • Or create a dedicated "update blocking" maintenance window that's always closed

After deployment, confirm behavior with this SQL query against the ConfigMgr database:


SELECT 
    ci.CI_ID,
    ci.CI_UniqueID,
    ci.DisplayName,
    d.CollectionID,
    d.OfferType,
    d.Enabled,
    d.SuppressReboot
FROM v_CIContentsAll ci
JOIN v_DeploymentInfo d ON ci.CI_ID = d.CI_ID
WHERE ci.DisplayName LIKE '%Critical Update%'
AND d.CollectionID = 'SMS00001'

Key values to validate:

  • OfferType should be 2 (Available)
  • SuppressReboot should be 1