none
Issue with replmgr RRS feed

  • Question

  •  

    I have software updates configured in my SCCM hierarchy. The wsus sync notifications from the parent site were being processed by the child site fine until sometime. Of late, I observed that the sync notification that was sent by the parent is being deleted by the child without processing it.

     

    the replmgr.log files throws the following info:

     

    Replication file D:\SCCM\inboxes\replmgr.box\incoming\8bfgyakh.RPT has an old transaction ID (Object Type = SMS_WSUS_SYNC_MANAGER, Object ID = CH1.SYN, Transaction ID = 2533), the current transaction ID is 3697, delete it.

     

    Any idea why this happens and any resolutions will be helpful.

    Tuesday, November 4, 2008 4:33 AM

Answers

  • Based on the design, if the registry value "Transaction ID" of sending site is smaller than the IDs stored in the destination site’s .TRS file, destination site’s replication manager will reject the replication file because it thought this file is an old file and can be ignored. Therefore, in this case, we need to increase the site’s transaction IDs to fix this issue.

    1. On the sending site find the following registry hive:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_REPLICATION_MANAGER
    Then in the right panel, find and write down the “Transaction ID” registry value.

    2. On the destination site open the SENDINGSITECODE.TRS file under the "<SCCM Installation folder>\inboxes\replmgr.box\history" folder. You may find a lot of transaction IDs for many components. Please check if the “Transaction ID” registry value on sending site is smaller than any transaction IDs stored in the sendingsitecode.TRS file on the destination  site.
    If so, write down the largest Transaction IDs stored in the sendingsitecide.TRS file on destination site.

    3. Then go to S51 site (sending site), change the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_REPLICATION_MANAGER | Transaction ID” registry value to a number which is larger than the largest IDs stored in the sendingsitecode.TRS file on the destination site.

    Tuesday, February 10, 2009 9:12 PM
  • This might happen if the parent site has been restored to an older version without resynchronizing the sites with the repair wizard.
    So yes, the way to fix this now  is to correct the transaction ID's as noted above.

    The way to prevent it is to make sure to carefully follow the recovery documentation and be sure to use the repair wizard because it will correct the transaction ID's for you after restoring the site.


    Stan
    Wednesday, February 11, 2009 12:34 AM
    Moderator

All replies

  • Based on the design, if the registry value "Transaction ID" of sending site is smaller than the IDs stored in the destination site’s .TRS file, destination site’s replication manager will reject the replication file because it thought this file is an old file and can be ignored. Therefore, in this case, we need to increase the site’s transaction IDs to fix this issue.

    1. On the sending site find the following registry hive:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_REPLICATION_MANAGER
    Then in the right panel, find and write down the “Transaction ID” registry value.

    2. On the destination site open the SENDINGSITECODE.TRS file under the "<SCCM Installation folder>\inboxes\replmgr.box\history" folder. You may find a lot of transaction IDs for many components. Please check if the “Transaction ID” registry value on sending site is smaller than any transaction IDs stored in the sendingsitecode.TRS file on the destination  site.
    If so, write down the largest Transaction IDs stored in the sendingsitecide.TRS file on destination site.

    3. Then go to S51 site (sending site), change the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_REPLICATION_MANAGER | Transaction ID” registry value to a number which is larger than the largest IDs stored in the sendingsitecode.TRS file on the destination site.

    Tuesday, February 10, 2009 9:12 PM
  • This might happen if the parent site has been restored to an older version without resynchronizing the sites with the repair wizard.
    So yes, the way to fix this now  is to correct the transaction ID's as noted above.

    The way to prevent it is to make sure to carefully follow the recovery documentation and be sure to use the repair wizard because it will correct the transaction ID's for you after restoring the site.


    Stan
    Wednesday, February 11, 2009 12:34 AM
    Moderator
  • Hi,

    Is issue resolved by changing registry value?

    Friday, May 15, 2015 9:30 AM
  • Hi,

    Is issue resolved by changing registry value?

    I had the same issue - I changed the registry value as described on the primary SUP AND restarted the SMS services afterwards.

    Without restarting the SMS services the regvalue changed back automatically.

    Friday, September 30, 2016 8:07 AM
  • Thank You Manoj.

    We are facing this issue after CAZ migration to Azure . After migration replmgr “Transaction ID”  on CAZ was lower than Primary “Transaction ID”.

    Changed below issue resolved.

    “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_REPLICATION_MANAGER  | Transaction ID” registry value to a number which is larger than the  largest IDs stored in the sendingsitecode.TRS file on the destination site.

    • Proposed as answer by RamPratap Yadav Wednesday, October 10, 2018 3:43 AM
    Wednesday, October 10, 2018 3:43 AM