SCCM – SkoaNOW Technologies

0x800b0109-A Certificate chain processed but terminated in a root certificate which is not trusted by the trust provider

StephenOwusuAnsah — Thu, 21 Nov 2024 04:31:51 +0000

Issue:

Windows updates are failing to install on the endpoints when deployed from SCCM
Error message is “Failed to install updates” and the error code is 0X800B0109.
The description of the error code is “A certificate chained processed, but terminated in a root certificate which is not trusted by the trust provider”.

Cause:

WSUS certificate may have expired a new one has been generated by SCCM.
The new WSUS certificate has been uploaded automatically to the Software Update Point that is being used to code-sign the updates from Microsoft.
Since the WSUS certificate has not been deployed to the endpoints then they do not trust the software updates coming from WSUS server.

Solution:

Navigate to the Trusted Root Certificate location on the SCCM server and export the WSUS certificate to a desired location.
Copy the WSUS certificate and deploy it to the endpoints using GPO.
Once the endpoints have received WSUS certificate in the Trusted Root Certificate Authority and Trusted Publishers in the Certificate console, then the endpoints will trust the updates code-signed using that certificate.

SCRIPT to automatically create System restore points for Winodws devices

StephenOwusuAnsah — Mon, 09 Sep 2024 01:45:48 +0000

Content

Scripts to enable system restore or system protection
Script to add a registry value that allows creation of multiple restore points in a 24 hour period
Script to add a task schedule that creates a restore point automatically

Scripts To Enable System Restore Or System Protection

This can be done into ways; one is to wrap the powershell script in a batch script and the other is to use WMIC.exe to create a batch script
Powershell wrapped in batch script: PowerShell.exe -ExecutionPolicy Bypass -Command “Enable-ComputerRestore -Drive ‘C:'”
WMIC.exe batch script: C:\Windows\System32\wbem\WMIC.exe /namespace:\root\default Path SystemRestore Call enable “C:\”

Script To Add A Registry Value That Allows Creation of Multiple Restore Points In A 24 Hour Period

By default Windows operating system does not allow more than one restore point to be created within a 24 hour period. To overcome this limitation, you can use this batch script to add a registry value that allows more than one restore point to be created in a 24 hour period; reg add “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore” /v SystemRestorePointFrequency /t REG_DWORD /d 0 /f

Script To Add A Task Schedule That Creates A Restore Point Automatically

Monthly Schedule: schtasks.exe /create /tn “Monthly Restore Point” /sc MONTHLY /d TUE /mo FIRST /st 10:00 /rl HIGHEST /ru “NT AUTHORITY\SYSTEM” /tr “PowerShell.exe -ExecutionPolicy Bypass -Command \”Checkpoint-Computer\” -Description \”AUTOMATIC-$(Get-Date -Format \”yyyyMMddHHmmss\”)\” -RestorePointType \”MODIFY_SETTINGS\””
Weekly Schedule: schtasks.exe /create /tn “Weekly Restore Point” /sc WEEKLY /d TUE /st 10:00 /rl HIGHEST /ru “NT AUTHORITY\SYSTEM” /tr “PowerShell.exe -ExecutionPolicy Bypass -Command \”Checkpoint-Computer\” -Description \”Weekly System Restore\” -RestorePointType \”MODIFY_SETTINGS\””
Daily Schedule: schtasks.exe /create /tn “Daily System Restore” /sc DAILY /st 09:00 /rl HIGHEST /ru “NT AUTHORITY\SYSTEM” /tr “PowerShell.exe -ExecutionPolicy Bypass -Command \”Checkpoint-Computer\” -Description \”AUTOMATIC-$(Get-Date -Format \”yyyyMMddHHmmss\”)\” -RestorePointType \”MODIFY_SETTINGS\””
tn=Task name; sc=schedule; d=Day; mo= st=Schedule time; rl=Run Level; ru=Run User; tr=Trigger

Combined Script for Daily Restore Point

@echo off

REM Enable System Protection or System Restore start /wait PowerShell.exe -ExecutionPolicy Bypass -Command “Enable-ComputerRestore -Drive ‘C:'”

REM Create Daily Restore Point
start /wait schtasks.exe /create /tn “Daily System Restore” /sc DAILY /st 09:00 /rl HIGHEST /ru “NT AUTHORITY\SYSTEM” /tr “PowerShell.exe -ExecutionPolicy Bypass -Command \”Checkpoint-Computer\” -Description \”AUTOMATIC-$(Get-Date -Format \”yyyyMMddHHmmss\”)\” -RestorePointType \”MODIFY_SETTINGS\””

REM Allow creation of multiple restore points in a 24 hour period
start /wait reg add “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore” /v SystemRestorePointFrequency /t REG_DWORD /d 0 /f

Exit

If you are packaging this as a WIN32 app in Intune, you can set the detection rule using the presence of the “SystemRestorePointFrequency“registry value.

Renew secret key values for SCCM-Intune comanagement applications

StephenOwusuAnsah — Fri, 02 Aug 2024 20:30:47 +0000

Using Cloud Attach to setup co-management of between SCCM and Intune creates two main Applications in Application Registry/Enterprise Applications; ConfigMgrSvc_XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX and Cloud Management.
By default the Secret Key duration is set to one year and so you need to set a calendar reminder to create a new secret key even though you will receive a reminder about 15days to the expiration date.
To renew the secret keys, in SCCM, navigate to Administration>>>Azure Directory Tenants. Click on the Tenant Name to display the corresponding Applications at the bottom of the page.
Right-click on each of the Enterprise Applications and click on Renew Secret Key.
When presented with the Office 365 log in screen, enter your Microsoft Entra ID/Office 365 account which has a Global Administrator or Cloud Application Administrator role associated with it and log in. Complete the associated MFA if it has been setup.
Once the process is successful, you will be presented with popup in SCCM indicating the renewal has been successful.
Log into the Application Registry in Azure and verify that the new secret keys have been created in the two applications.
Note: Do not renew the secret keys from Application Registry/Enterprise Applications in Azure because it may not be able to sync with SCCM. Correct process is to renew the secret keys from the SCCM side.

SCCM/MECM Troubleshooting

StephenOwusuAnsah — Thu, 22 Feb 2024 12:56:35 +0000

SCCM Error Codes

The “Requested Object Information could not be retrieved” SCCM Error

StephenOwusuAnsah — Wed, 14 Feb 2024 12:02:11 +0000

Issue: When I try to view, edit or create a new task sequence in SCCM, an error message is displayed “The requested object information could not be retrieved. Refresh the Configuration Manager console to verify that another administrator has not moved or deleted the object, or that the role-based administration security scopes or security roles for the object or current user have not changed“.

Solution: Close Configuration Manager console and then open command prompt as administrator on the SCCM server. If Microsoft Configuration Manager is installed in the C-drive then type; cd “C:\Program Files\Microsoft Configuration Manager\bin\X64” (to change directory to the location of the TaskSequenceProvider.mof file)

C:\Program Files\Microsoft Configuration Manager\bin\X64> MofComp.exe TaskSequenceProvider.mof ( run this to recompile the TaskSequenceProvider.mof package)>>>press Enter on the computer keyboard to execute the command.

After running the command, you should see the information below indicating that it has executed it successfully;

Microsoft (R) MOF Compiler Version X.X.X.XXXXX
Copyright (c) Microsoft Corp. 1997-2024. All rights reserved.
Parsing MOF file: TaskSequenceProvider.mof
MOF file has been successfully parsed
Storing data in the repository...
Done!

Open the Configuration Manager console again, navigate to the Task Sequence and try to view, edit or create a new task sequence and it should work without issues.