SCCM Backlog fighting

One of the “usual” issues in big SCCM environments is backlogging. Once number of files in an inbox reached critical level SCCM has no chance to keep up unless you stop all data transferring between sites for several days. And it is not because of SCCM only. Try to run “DIR /p” command in folder with million files and you will see it takes 3-5 minutes. Windows Explorer hangs when you try to open such folders especially when files are changing.

I’ve seen 2 million files in replmgr.box inbox and million in distmgr.box. In CompSumm.Box I never had so many files but total size of them was huge — 100GB.

All you changes may be delayed for days and even weeks or changes already happened on client side (package installed, new inventory date, etc) but SCCM server doesn’t know that because it has not processed status files yet.

So how you can help SCCM to get back on the trail?

First at all stop all SMS_ $$$$$ services. It may take up to 10-15 minutes to stop SMS_EXECUTIVE service but it’s very important to stop it gracefully. Don’t kill smsexec.exe process!

Then create “DELAY” folder under <SCCM_INSTALL_PATH>\inboxes\replmgr.box\incoming
and move all RPT files from replmgr.box\incoming to delay folder. I’ve noticed RPL files can be processed much quicker than RPT. So RPLs can be left.
Start SMS_SITE_COMPONENT_MANAGER service. In a few seconds it will start SMS_EXECUTIVE and other service if required.
Watch replmgr.box\incoming folder. Once SCCM finished processing old files (number of files in the folder will be dropped) you can start moving back RPT files. It should be done in blocks.

One of my colleague gave me a script for it

@echo off & setlocal EnableDelayedExpansion
set LIM=300
for %%i in (*.rpt) do (
set /A N+=1
move “%%i” “..”
if !N! geq !LIM! (TimeOut 3600 & set /A LIM+=300)
)
:DONE

Save it into DELAY folder. Depends on the backlogging server performance you might increase or decrease the file limit or timeout.
I ran the script on some of servers. The longest run was 8 days but during that time all SCCM infrastructure responded as expected. It was critical for patch management process.

Advertisements

About oleggap

IT Pro
This entry was posted in SCCM. Bookmark the permalink.