SCCM Replication Issue – SQL Replication Troubleshooting Guide

SCCM Database replication issues are common when you have an SCCM hierarchy with CAS, Primary, or Secondary servers. Let’s check what the necessary troubleshooting steps an SCCM admin can perform are.

SCCM replication issue is not very easy to troubleshoot via forums or offline.  The above SCCM Replication Issue troubleshooting video will help you fix some of the common SCCM replication issues.

Latest Updated Post – FIX SCCM SQL Replication Issues Using Replication Link Analyzer

3 thoughts on “SCCM Replication Issue – SQL Replication Troubleshooting Guide”

  1. Hi Anoop
    As u mentioned above topics like sccm is going to read only mode. Second one is SCCM CAS server will be in maintenance mode, and it will be waiting for the primary server to send data. help me in the both cases. I am facing these issues .. It’s my request to you make a blog particularly on these issues.

    • Thanks for your reply. I had go through your blog related to this issue. But what I am asking is if the there’s link failed issue then why it’s going to read only mode… I want to know the root cause about this particular issue.. and what could be the solution. There are only 3 link status like link active, degraded and failed.. but I have seen the link is being unknown.
      In this blog also there are some reason behind this issue but not specifically. And most importantly there’s no particular solutions for this issue…

      [Looking at the ReplicationLinkAnalysis.XML file placed on the desktop we have more info about the testing done by the replication link analyzer including where it failed, namely during the DoesBrokerConfigurationExist on P01.

      Now we know our issue is related to the SQL Broker Service, so we should check out the error log for SQL to see what it says, that error log is located at D:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\ErrorLog and that revealed SQL error 3961 which is:

      Snapshot isolation transaction failed in database ‘%.*ls’ because the object accessed by the statement has been modified by a DDL statement in another concurrent transaction since the start of this transaction. It is disallowed because the metadata is not versioned.

      Ok at this point it looks like the SQL database on P01 is confused, probably due to server load at the time of booting up the server, and due to the fact that the SQL server itself was sitting on the same PID since the 4th of July along with more than two weeks of the virtual machine being in a saved state. I could wait some more or try restarting the SMS Executive service or a reboot of the server. As this is my LAB I had enough of the troubleshooting and did a reboot.

      After the reboot (of P01) I ran the Replication Link Analyzer again (on CAS) and this time the SQL Broker Service on P01 was working however the site was still replicating, a few minutes later in rcmctrl.log I could see that the Current Site Status had finally changed to ReplicationActive.]
      Rebooting may be a part of
      every solutions but there should be more way to solve this.


Leave a Comment