SCCM High CPU Usage

Just finished patching 50 servers that hadn’t been patched for a couple of years… and yes it took forever. But its done now. Just finally finished applying the June2019 patches and it was a breeze cause there was only 5 patches to deploy instead of 200.

Noticed over the last 2-3 weeks that the SCCM server was taking a while to report and SCCM was reporting high CPU during this time and throughout the night.

NP – running a single SCCM Primary Site server.

The below article from Microsoft describes high CPU and memory usage:

https://blogs.technet.microsoft.com/configurationmgr/2017/08/18/high-cpuhigh-memory-in-wsus-following-update-tuesdays/

I almost skipped this article because didn’t think it affected me until I realize I have 4 Windows 10 1703 workstations.

Maybe time to upgrade them to Windows 10 1903……

Applied the fixes and CPU utilization dropped from an average of 40% to 15%. Big improvement.

Context Has Expired Error – SharePoint

Came across this error during health checks.

---

{Microsoft.SharePoint.SPException: The context has expired and can no longer be used. (Exception from HRESULT: 0x80090317) —> System.Runtime.InteropServices.COMException (0x80090317): The context has expired and can no longer be used. (Exception from HRESULT: 0x80090317)

---

An IIS Reset on the server will resolve the issue.

 

Missing Patches – SCCM

Was patching over the weekend especially with the Remote Desktop Gateway bug deemed critical.

Noticed that none of the Windows Server 2012 R2 and Windows Server 2016 updates were  not appearing in SCCM.

Thought it was my WSUS server (in my internet facing environment) not downloading Windows Server updates. Confirmed by checking my WSUS.

Then remembered that SCCM also manages Updates as well.

See below process:

Go to Administration > Site Configuration > Sites.

Click on the Primary Site and then click Settings from the top pane.

Select Configure Site Components then Software update Point.

Click the Products tab.

Tick Windows Server 2012 R2 and Windows Server 2016.

Click Ok.

Go to Software Library > Software Updates.

Right click on All Software Updates and select Synchronize Software Updates.

The newly ticked classifications will sync and you will see the ‘new’ updates under All Software Updates.
Ready to deploy.

This caught me out this weekend. Luckily I remembered and fixed it quickly without too much effort.

 

Event ID: 8031 – Requested Application Could Not Be Found

While verifying an issue with our local SharePoint instance, noticed in event logs on one of the SharePoint Application servers that one of the Application Endpoints couldn’t be found.

Event ID: 8031 – The request application could not be found.

This is related to an old Service Application that was deleted but didn’t delete all endpoints from all servers in the SharePoint Farm.

To resolve this error, you need to clean up the database for this application.

Open SQL Server where your content database sits.

Write the command into the script:

SELECT ID, Name, Status, Properties
FROM .dbo.Objects
WHERE NAME LIKE ‘%%’
GO

Eg.

SELECT ID, Name, Status, Properties
FROM ContentDB.dbo.Objects
WHERE NAME LIKE ‘%285C%’
GO

Confirm that the name column matches the GUID in the logs.

Run the following script in SQL Server to remove the endpoint from the database:

DELETE *
FROM dbo.Objects
WHERE Name LIKE ‘%285C%’
GO

Perform an IISReset on the affected server.

SharePoint 2019 Database Requirements

Was recently reviewing the SharePoint 2019 requirements when I noticed a change in the requirements compared to previous versions of SharePoint.

The change is that as long as SQL Server version supports the Database Compatibility Level 130, then you can use whatever version you require.

Source – https://docs.microsoft.com/en-us/sharepoint/install/hardware-and-software-requirements-2019

This helps with migrations and upgrades when certain versions of SQL Server go end of life.

This is perfect for people like my client who are running SharePoint 2010 on SQL Server 2008 R2. SQL Server 2008 R2 has gone end of life from extended support back in July 2019, so when we migrate to SharePoint 2019 we can provide rolling SQL Server upgrades without having to perform a complete SharePoint migration just because SQL Server is end of life.