Remove Recurring Schedules from Device Collections in SCCM Before Upgrading to 1810

Adam GrossSCCM16 Comments

Today I upgraded my production SCCM/ConfigMgr environment from 1806 to 1810, but before I did, I took care of some housekeeping that saved me a fair amount of work on the backend. If you’re like me, you try ensure that your collections aren’t being refreshed unnecessarily. For collections where I have direct or include/exclude rules, I always uncheck the incremental and scheduled refresh boxes when setting up the collection. However, there’s one extra step that I haven’t been doing that requires just a bit of consideration before upgrading to 1810. The picture below is the setting in question.

Uncheck to set RefreshType to Manual

The Issue

The Release Notes for SCCM 1810 state the following:

Previously, when you configured a schedule on a query-based collection, the site would continue to evaluate the query whether or not you enabled the collection setting to Schedule a full update on this collection. To fully disable the schedule, you had to change the schedule to None. Now the site clears the schedule when you disable this setting. To specify a schedule for collection evaluation, enable the option to Schedule a full update on this collection.

https://docs.microsoft.com/en-us/sccm/core/plan-design/changes/whats-new-in-version-1810#improvements-to-collection-evaluation
SCCM Remove Recurring Schedules Collections Script
Change Recurrence pattern to None

If you’re like me, you likely have scheduled refreshes happening for collections that you thought you’d disabled it on. In my prod environment, I have 2200+ collections and 1750 collections were affected by this issue.

If you have NOT already upgraded to ConfigMgr 1810, you can use the following PowerShell script to change disable the schedule to None for all of the collections where the checkbox has been unchecked.

If you have already upgraded to 1810, this script won’t help since any collections in this state prior to the upgrade are were updated to Periodic (RefreshType 2). Eswar Koneti has a great post and script to help you further.

Finding Affected Collections

Collections with the Schedule checkbox unchecked but with an active schedule can be found using the ConfigMgr PowerShell cmdlets. If you run this query before upgrading to 1810, you should expect to find some collections.

#Returns all Collections with a recurring collection and RefreshType of manual.
Get-CMDeviceCollection | Where-Object RefreshType -eq 1 | Where-Object {$_.RefreshSchedule.SmsProviderObjectPath -ne "SMS_ST_NonRecurring"}

If you run the above collection on 1810, you won’t find any collections in this state. Instead they will all have RefreshType 2 and can be found with this query:

#Returns all Collections with a recurring collection and RefreshType of Periodic.
Get-CMDeviceCollection | Where-Object RefreshType -eq 2

SCCM Remove Recurring Schedules Collections Script

The script is commented and walks through what each step does. The script simply selects all collections where RefreshType is 1 and RefreshSchedule is not SMS_ST_NonRecurring then updates the RefreshSchedule with a non-recurring schedule.

<#

    .SYNOPSIS

        Find all collections with a RefreshType of 1 (Manual) that have a recurring schedule set and update the schedule to non-recurring (None).

    .NOTES

        Author: Adam Gross

        Twitter: @AdamGrossTX

        Website: https://www.asquaredozen.com

    .LINK
        Originally posted on http://www.SystemCenterDudes.com

    .HISTORY

        1.0 - Original
#>

[cmdletBinding()]
param(
    [Parameter(Mandatory=$true)]
    [string]
    $SiteCode,
    
    [Parameter(Mandatory=$true)]
    [string]
    $ProviderMachineName
)

#Connect to ConfigMgr
$initParams = @{}
if((Get-Module ConfigurationManager) -eq $null) {
    Import-Module "$($ENV:SMS_ADMIN_UI_PATH)\..\ConfigurationManager.psd1" @initParams 
}

if((Get-PSDrive -Name $SiteCode -PSProvider CMSite -ErrorAction SilentlyContinue) -eq $null) {
    New-PSDrive -Name $SiteCode -PSProvider CMSite -Root $ProviderMachineName @initParams
}

Set-Location "$($SiteCode):\" @initParams

#######################################################

#Set New Blank Schedule
$Schedule = New-CMSchedule -Start "01/01/2019 12:00 AM" -DurationInterval Minutes -DurationCount 0 -IsUtc:$False -Nonrecurring

#Get All Collections
$AllCollections = Get-CMDeviceCollection
Write-Host "Total Collections Count is: $($AllCollections.Count)"

#Filter to TargetCollections based on RefreshType of 1 which is Manual
$ManualRefreshCollections = $AllCollections | Where-Object RefreshType -eq 1
Write-Host "Total Collections with RefreshType of 1 is: $($ManualRefreshCollections.Count)"

#Get Collections with a RefreshSchedule that is recurring.
$RecurringCollections = $ManualRefreshCollections | Where-Object {$_.RefreshSchedule.SmsProviderObjectPath -ne "SMS_ST_NonRecurring"}
Write-Host "Total Collections with RefreshType of 1 and RefreshSchedule of Recurring: $($RecurringCollections.Count)"

$Count = 0
#Loop through each RecurringCollection and update the schedule to be non-recurring 
ForEach($Collection in $RecurringCollections)
{
    $Count ++
    Write-Host "#############################"
    Write-Host "Processing Record $($Count) of $($RecurringCollections.Count): $($Collection.Name)"
    $Collection | Set-CMDeviceCollection -RefreshSchedule $Schedule
    Write-Host "Updated: $($Collection.Name)"
}

You can download the latest copy of the script from the GitHub Repo.

1 Star2 Stars3 Stars4 Stars5 Stars (4 votes, average: 5.00 out of 5)
Loading...

Share this Post

16 Comments on “Remove Recurring Schedules from Device Collections in SCCM Before Upgrading to 1810”

  1. Thanks again for the insight Adam. Wanted to reply to the previous thread but it would not let me. I have read both blog posts now and I think I have everything now, just want to make sure what I understood was correct.

    – collections with direct membership only — no schedule required
    – collections with query — schedule accordingly

    – collections with include/exclude — either manual update, scheduled accordingly or incremental refresh (based on parent collection) – that is if you want the collection to update when the include/exclude collection updates

    – collections with combination of membership options –same as above

    1. One other question. If you have a collection that is direct membership for an AD group and then you include another collection which is also a direct membership for other AD groups. For example we have a collection for software deployment to Software Center that would allow specific users access, but we also want to include our support teams but don’t want to have to define those AD groups for each collection.

      Would you need to set the schedule because the collection has an include?

  2. Pingback: SCCM Collection Evaluation - Troubleshooting Incremental Update Issues - A Square Dozen

  3. Pingback: My First Post for System Center Dudes - "Remove Recurring Schedules from Device Collections in SCCM Before Upgrading to 1810" - A Square Dozen

  4. Adam thanks for the script. Curious why you don’t have your query-based collections updating on a schedule. I understand Direct Rules but not understanding why you also exclude query-based collections. Which type of collections do you set collection updates on? Do you have a best practice?

      1. Thanks for the clarification Adam much appreciated. I am going to assume that the reference collections that are used to populate other collection for Include/Exlude rules are set to incremental or scheduled.

        i.e. You have a collection, colB, that has and include rule from ColA. ColB has both incremental and scheduled unchecked and the schedule set to none, but colA is a query rule so it has a schedule associated with it.

        1. Correct. I tested that again today to verify. Include/exclude are automatic when the parent coll is refreshed.

          You can watch Ceviewer on the server and see what happens when you trigger a refresh on a top level collection.

          1. Thanks for the clarification and the verification. Guess I have a little bit of work to do, the last person that managed our environment created include/exclude collections with schedules. We do have some collections that have both a combination of queries and include/exclude so I could understand the need to have those scheduled.

            Is there a way to capture which collections have what? i.e. Direct Only, Direct + Include/Exclude, etc.

            I was reading through the link you provided and it mentioned that for user collections you can AD group direct membership for user based AD groups. Go you have to import these groups into SCCM or are they done automatically. Right or wrong we have 1000s of AD groups, some with computers others with users, don’t really want to import all those groups if I don’t have to. Right now we are just adding the groups we want into the Group Discovery. The old admin created a query rule for those groups, but if I am reading this correctly I can do a direct membership of the AD group and I don’t need a scheduled update.

          2. Thanks for the reply. First, for AD Groups in SCCM, you can configure AD Group discovery to import whichever groups you want to use for your user collections. No need to import them all. Then you can change your query rules to direct rules with the group as the only member.

            As for identifying which collections have which configuration, the script in the post provides a baseline for doing that, you can just change it to find the collections with the attributes you want.

            I have also recently revisited collections and made some new discoveries. Please read my post here https://www.asquaredozen.com/2019/02/21/sccm-collection-evaluation-troubleshooting-incremental-update-issues/.

            Also, this blog post talks about how to identify the different types of collections in PowerShell.

            https://blogs.technet.microsoft.com/leesteve/2017/08/22/sccm-for-those-nasty-incremental-collections/

  5. Thanks Adam! I had this issue in our test environments. The cmupdate.log continued to fail on a Microsoft bug article. I eventually opened a case, and the Microsoft engineer provided a script to perform the steps you mention above.

    Also, everyone remember to update the SQL Native Client; otherwise, the pre-req will fail.

Leave a Reply

Your email address will not be published. Required fields are marked *