Support Tip: The data in statusreportingctrl.ct0 may be reset if recovering only the site database in ConfigMgr 2012

Support Tip: The data in statusreportingctrl.ct0 may be reset if recovering only the site database in ConfigMgr 2012

  • Comments 1
  • Likes

~ Winds Wu | Support Engineer

ToolsWe recently came across an issue related to restoring the site database in System Center 2012 Configuration Manager Service Pack 1 (ConfigMgr 2012 SP1) and we wanted to make you aware of it in case you happened to see it. There is no functional impact that we’ve been able to determine but it may raise some questions if you see the errors.

Issue: If you only recover the site database in ConfigMgr 2012, the data in statusreportingctrl.ct0 will be reset back to its original version.

Repro Steps

1. On a ConfigMgr Primary Site Server, backup the site sever & database.
2. Remove the database from the site server.
3. Run the recovery wizard from the SP1 RTM CD to only recover the database.
4. Finish the recovery.

Expected Result:
The data in <SMS installation folder>\scripts\statusreportingctrl.ct0 would be the same as the file before the recovery.

Actual Result:
The <SMS installation folder>\scripts\statusreportingctrl.ct0 is replaced with the file from SP1RTMCD (1KB). The original data in the file is lost.

The result is that you will see errors in SMSEXEC.log similar to the following:

CServerStatusReporter::RefreshFilter(): ERROR: The control file does not contain a configuration item named "Server Component Status Reporting".

This is currently scheduled to be addressed in a future version of the product but in the meantime, be sure to backup the statusreportingctrl.ct0 before performing a site database recovery, then copy it back after the recovery is complete.

Winds Wu | Support Engineer | Microsoft GBS Management and Security Division

Get the latest System Center news on Facebook and Twitter:

clip_image001 clip_image002

System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm

Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The AD RMS blog: http://blogs.technet.com/b/rmssupp/

App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv

The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • It looks like the same thing happens in my testing with configuration.mof.  Backup does back it up, but restore puts back down default configuration.mof.  This is a problem for clients like us who have done lots of configuration.mof edits.