Strange ADR behaviour

Copper Contributor

I'm stucked here.

Suddenly our ADRs are not running, either on schedule or with "Run Now".

We are on ConfigMgr CB 2103.

My ruleengine.log says:

Refreshed ScheduleList instance for Rule (18) from schedule string (89C95BC000231600) with next occurence (21-09-2021 14:34:00) $$<SMS_RULE_ENGINE><09-16-2021 15:01:31.854-120><thread=4076 (0xFEC)>
Refreshed ScheduleList instance for Rule (19) from schedule string (15E95BC000231600) with next occurence (21-09-2021 15:05:00) $$<SMS_RULE_ENGINE><09-16-2021 15:01:31.854-120><thread=4076 (0xFEC)>
Refreshed ScheduleList instance for Rule (20) from schedule string (EE095BC000231600) with next occurence (21-09-2021 16:59:00) $$<SMS_RULE_ENGINE><09-16-2021 15:01:31.855-120><thread=4076 (0xFEC)>
Refreshed ScheduleList instance for Rule (24) from schedule string (14743C4000241600) with next occurence (20-10-2021 03:05:00) $$<SMS_RULE_ENGINE><09-16-2021 15:01:31.855-120><thread=4076 (0xFEC)>
Refreshed ScheduleList instance for Rule (26) from schedule string (02F64C8000100100) with next occurence (16-09-2021 16:00:00) $$<SMS_RULE_ENGINE><09-16-2021 15:01:31.855-120><thread=4076 (0xFEC)>
Refreshed ScheduleList instance for Rule (27) from schedule string (B6F64C8000231400) with next occurence (12-10-2021 23:45:00) $$<SMS_RULE_ENGINE><09-16-2021 15:01:31.856-120><thread=4076 (0xFEC)>
Refreshed ScheduleList instance for Rule (28) from schedule string (00B64C80001D2000) with next occurence (23-09-2021 05:00:00) $$<SMS_RULE_ENGINE><09-16-2021 15:01:31.856-120><thread=4076 (0xFEC)>
Refreshed ScheduleList instance for Rule (29) from schedule string (02764C8000331500) with next occurence (18-09-2021 19:00:00) $$<SMS_RULE_ENGINE><09-16-2021 15:01:31.856-120><thread=4076 (0xFEC)>
Refreshed ScheduleList instance for Rule (30) from schedule string (00945C8000100008) with next occurence (17-09-2021 04:00:00) $$<SMS_RULE_ENGINE><09-16-2021 15:01:31.856-120><thread=4076 (0xFEC)>
Refreshed ScheduleList instance for Rule (31) from schedule string (3E11CC8000231400) with next occurence (12-10-2021 16:15:00) $$<SMS_RULE_ENGINE><09-16-2021 15:01:31.857-120><thread=4076 (0xFEC)>
Refreshed ScheduleList instance for Rule (32) from schedule string (3D709CC000100100) with next occurence (16-09-2021 15:15:00) $$<SMS_RULE_ENGINE><09-16-2021 15:01:31.857-120><thread=4076 (0xFEC)>

 

** I don't have that many ADRs...

In powershell:

$ADRs = Get-CMSoftwareUpdateAutoDeploymentRule -fast
foreach ($ADR in $ADRs){
write-host $ADR.AutoDeploymentID " " $ADR.Name
}

gives this result:

26 WRK Win10 Updates
27 WRK Applikation Updates
28 WRK Edge Updates
29 Office 365 Updates
30 WRK ZeroDay updates
31 WORKGROUP Windows updates
32 WRK Win 10 Updates !

 

How do I clean up these "ghost"-adrs ?

My ADRs get stuck in:

4 update(s) need to be downloaded in package "ASE0033C" (\\sccm01\Packages\Updates\2020_All_Updates) $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.533-120><thread=7652 (0x1DE4)>
List of update(s) which match the content rule criteria = {17026392,17026605,17026617,17026621} $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.533-120><thread=7652 (0x1DE4)>

Downloading contents (count = 1) for UpdateID 17026392 $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.534-120><thread=7652 (0x1DE4)>
List of update content(s) which match the content rule criteria = {17001372} $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.534-120><thread=7652 (0x1DE4)>
Contents 17001372 is already present in the package "ASE0033C". Skipping download. $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.535-120><thread=7652 (0x1DE4)>
Downloading contents (count = 1) for UpdateID 17026605 $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.602-120><thread=7652 (0x1DE4)>
List of update content(s) which match the content rule criteria = {17001545} $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.603-120><thread=7652 (0x1DE4)>
Contents 17001545 is already present in the package "ASE0033C". Skipping download. $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.604-120><thread=7652 (0x1DE4)>
Downloading contents (count = 1) for UpdateID 17026617 $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.681-120><thread=7652 (0x1DE4)>
List of update content(s) which match the content rule criteria = {17001551} $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.682-120><thread=7652 (0x1DE4)>
Contents 17001551 is already present in the package "ASE0033C". Skipping download. $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.683-120><thread=7652 (0x1DE4)>
Downloading contents (count = 1) for UpdateID 17026621 $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.746-120><thread=7652 (0x1DE4)>
List of update content(s) which match the content rule criteria = {17001553} $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.746-120><thread=7652 (0x1DE4)>
Contents 17001553 is already present in the package "ASE0033C". Skipping download. $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.747-120><thread=7652 (0x1DE4)>
No new update was added to the package. Package "ASE0033C" would not be updated. $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.747-120><thread=7652 (0x1DE4)>
Download action completed for the AutoDeployment $$<SMS_RULE_ENGINE><09-16-2021 15:01:32.747-120><thread=7652 (0x1DE4)>

** After this, no more ADRs run or download..

 

Anyone with a hint on this ?

TIA

4 Replies
I can add that a lookup in the SCCM DB - dbo.rules - gives this view:
RuleID Name Description
18 Microsoft Updates (Test): Office 2013
19 Microsoft Updates (Test): Windows 7
20 Microsoft Updates (Test): DOT-NET-Framework
24 Test - Office 2016
26 WRK Win10 Updates Monthly updates for Win10 systems
27 WRK Applikation Updates
28 WRK Edge Updates Edge Chromium updates
29 Office 365 Updates Office 365 Updates
30 WRK ZeroDay updates
31 WORKGROUP Windows updates Windows Updates for Windows 10 Home 64-bit 20H2
32 WRK Win 10 Updates ! ADR Issue test - new

So - the good questions is now: How to remove these "ghosted" rules (that are NOT in the console) from the database, to make the ruleengine run again ?
Unless you're proficient with T-SQL you may have to open up a ConfigMgr Support ticket and ask a Support Engineer to go in there and delete those tables for you.
Hi,
Have you got a lot of 0 bytes files in %windir%\temp ?
If yes, delete these files and try to run your ADRs
Hi
Thx all for your suggestions.
I sent a "frown" through the console, and got a reply back from the configmgr-team:
"This issue should have been fixed in 2103 Hotfix Rollup, and of course 2107."
The hotfix was not installed.
I did the update to 2107 - and now the ADRs are running.
I still have the "ghosted" rules, but they are not blocking for the other rules.
I will, though, open a MS support ticket, to get these rules removed from the DB.