SCCM 1802 is the latest baseline version used for clean installs.
SCCM 1806 is an update to 1802 and the most effective way to install is using an SCP and the update is presented in the console.
If you are impatient for the latest release and it is not in the console you can hurry it up using the EnableFastUpdateRingXXXX.ps1 script that Microsoft provide – where XXXX is the new version number. The script uses the site server name as its only parameter, e.g. .\EnableFastUpdateRing1806.ps1 CM01 where CM01 is the site server name.
More info here:
Check the ADK version and if need to update do this before the SCCM in-console update. Remove the existing ADK and then install the newer version. More info here:
Also a good idea to temporarily stop any site maintenance tasks while running the update.
Full pre-install checklist here:
Suggest you run the prereq check before starting the install and address any highlighted issues.
Thanks to Mr Brady and the System Center Dudes for their continued excellent contributions to the SCCM community.
Well known configuration that needs applying to domain controler after the SCOM agent is installed.
Clue that this has not been done is that the relevent domain controller will show in the SCOM console as not monitored.
- Open an elevated command prompt.
- Navigate to the agent install folder on the domain controller, typically C:\Program Files\Microsoft Monitoring Agent\Agent.
- Run – HSLockdown.exe /A “NT AUTHORITY\SYSTEM”
- Restart the SCOM agent service – run net stop healthservice & net start healthservice
Thanks yet agin to Kevin Holman.
Easy way to test a connection to an OLEDB data source.
- Save an empty file to desktop with a UDL extension.
- Double-click to open and use the Data Link tool to test connectivity to the required source using the choice of providers.
Used this tool when troubleshooting a failed SCCM 1702 install. Logs indicated SQL native client error. Tested connection to SCCM DB using this tool using the server name (worked) and then FQDN (failed). Found a reg key to change this setting. Restarted the SCCM 1702 install and it worked!
- Access the Administration workspace in the SCCM Admin Console.
- Expand Site Configuration.
- Right click on Sites and select Hierarchy Settings.
- In the Hierarchy Settings Properties dialogue ensure the General tab is selected and select Consent to use Pre-Release features radio-button.
- Click OK.
- Still in the Administration workspace expand Updates and Servicing and select Features.
- In the details pane select the required pre-release feature, right-click and select Turn on.
- Acknowledge the warning message by clicking Yes.
The above is based on SCCM CB 1706.
Running the install for SCCM Current Branch (1702) and the Prerequisite Checker was failing on an issue with admin rights on the target SCCM Site Server. This one was really annoying as I had double-checked everything before running the installer.
The appropriate accounts had been given admin rights to all the SCCM Site System Servers using the Restricted Groups Active Directory Group Policy setting (under Security Settings, under Windows Settings, under Computer Policies) . The SCCM server had not been restarted since the policy was applied.
Restarting the server fixed the issue!
Attempting to automate some maintenance schedules using the new SCOM 2016 functionality and received the following error:
The Execute Permission Was Denied For Object ‘sp_help_jobactivity’.
Assign the following rights for the SCOM Data Access Service account (SDK service) against the msdb database:
As always many thanks to Kevin Holman – more info about this issue here: https://blogs.technet.microsoft.com/kevinholman/2016/10/22/enabling-scheduled-maintenance-in-scom-2016-ur1/
SCCM Current Branch (1702).
Automatic Deployment Rule was running without error but not doing anything. Downloading updates manually was working so not a problem with Internet connection etc.
The share/folder on the SCCM Site Server where the software updates were meant to download to (the Package Source folder) needed a tweak to the permissions.
Add the server SYSTEM account to the permissions for the folder and the share with the appropriate rights to be able to write to both.
See a full list of Windows Server 2016 and/or Windows 10 maintenance tasks using the following command run from an admin command prompt:
Somebody somewhere thought not having the WindowsUpdate.log in a human readable format that could be viewed in real-time was a really good idea.
To read the logs now you have to use a PowerShell command.
Open PowerShell using Run As Administrator and run the following.
Wait patiently for the now out-of-date log to save to your desktop.