SCCM – Backup Software Update Groups

Blog Admin • 13 September 2018

There are many situations in which the integration between SCCM & WSUS being the SUP (Software Update Point Role) may gather issues along the way, so it’s important to have these backed up besides the actual SCCM database via the Site Backup maintenance task.

As these objects do not contain an export function for a .MOF file extension, there is another method in which this can be done via PowerShell.

So we will go through the following


  • Backup of the Software Update Groups
  • Recovery of the Software Update Point Groups

With SUGs they contain the WSUS updates which would have already been synchronized into SCCM, so if recovering from any disaster situation these would also count as objects which would have to be re-created in order to support you WSUS patching schedules if utilising these.

Though you can indeed run a report on the SUGs and obtain a detailed list of each SUGs updates, you will still need a method to re-create this without needing to go through the administrative effort of recreating them manually.

Backup of the SUGs

So firstly you will need to obtain the lists of the SUGs as well as the updates within them so use the following lines.

$SUGs = Get-CMSoftwareUpdateGroup | ForEach-Object {$_.LocalizedDisplayName}
ForEach ($SUG in $SUGs) {(Get-CMSoftwareUpdate -UpdateGroupName $SUG | ForEach-Object {$_.LocalizedDisplayName}) | Out-File <Directory to file>.$SUG.csv}

This should allow you take a record of each of the SUGs and also all of the windows updates that are contained within them.

Recovery of the SUGs

These lines focus on an individual recovery of each depending if only one or all are missing.

$SUG = “” # Add Software Update Group Name Here
$CheckIfExists = Get-CMSoftwareUpdateGroup – Name $SUG
If ($CheckIfExists -ne $null) {Write-Host “Software Update Group Already Exists”} Else {Write-Host “Software Update Group does not exist and needs to be created”; New-CMSoftwareUpdateGroup -Name $SUG}

$UpdatesExport = Import-CSV <Directory to File> -Header Updates # Add location of the exported file in the quotation marks
$UpdatesExport | ForEach-Object {$_.Updates} {Add-CMSoftwareUpdateToGroup -SoftwareUpdateGroupName $SUG -SoftwareUpdateName $_.Updates}

This should be able to achieve the following


  • Check if the SUG exists and if not create it
  • Add any missing windows updates which should belong to the SUG

Create these scripts and save them, Ideally have the Backup SUG lines run on a suitable interval to have a checkpoint of them.


Your business can become more effective with system centre automation. Get in touch with Walsham Solutions for your system centre training today.

by D Walsham 13 December 2021
Looking through the current SQL Server topology and how it affects our decision
by D Walsham 7 October 2021
Introduction
by D Walsham 6 October 2021
Introduction
by D Walsham 12 August 2021
All the parts of the series we went into great detail about how we analyse an end to end solution and how we would design a solution in which would allow us to build endpoints without SCCM being a dependency. Whilst we did this, there is another scenario which we have not touched on yet, which is the hybrid scenarios. In a perfect world ideally you would have your Azure Active Directory within the cloud, every machine meets the recommended requirements for Windows 10, everything is imported into Intune/Autopilot and everyone is happy. But we know this isn't realistic in all cases. Many organisations cannot just simply up and go from on-premise into the cloud therefore the checkpoint here is of course getting into hybrid solutions such as; Co-Management Between Intune and SCCM Hybrid AD with Azure AD and On-Premise AD syncing together These things can play a very interesting part in how you would tackle this if you envisage the next step in the blueprint is to be in a position in which you can build and manage endpoints soley within Intune. With this final part of the series we will go in-depth in how the common hybrid setups look like and how we go about moving into the next step of being able to manage and build devices without SCCM.
by D Walsham 29 July 2021
In continuation from the previous part where we had discussed how we create the "on site" piece of the solution, this was the part which would allow us to get our endpoints into a state in which they would essentially be ready to go through the Autopilot process. Which leaves our next piece of the puzzle, to begin the configuration of the actual backend side that resides within our Endpoint Management console. And you will see how everything ties up together to satisfy the full end to end process of getting an unknown (or known) device to proceed thorough the whole workflow to be finally managed by Intune without the aid of SCCM taking part in any of the prerequisites or preparation at hand.
by D Walsham 15 July 2021
In this part we are now going to look into the technical step by step points on how we put everything together. In the previous part we spoke about the structure of how we would asses whether a machine was actually ready to be built with Autopilot or not with a build checklist process which would step through all areas which would cover an endpoints eligibility. Now with everything planned out we finally want to step into making things reality by putting everything together.
by D Walsham 2 July 2021
When it comes to managing your endpoints in endpoint manager, one of the things you may be looking to do is to get all of your Intune registered machines to also be enrolled as Autopilot devices. Now we can of course just have the deployment profile deployed to all machines and then hit the "Convert targeted machines to autopilot" but this might not necessarily be feasible for every client. We may want to perform some due diligence first so we can at least understand what devices in Intune are not in Autopilot.
Show More