Secondary site SC_Address table replication issues, distribution point rate limits ignored on DP's attached to secondary site

I'm having an issue with distribution points attached to secondary sites ignoring rate limits defined.  This issue only happens to site servers/distribution points that failed to install the first time or were deleted and then recreated with the same FQDN and only when attached to secondary sites.  When doing the same on the primary sites it works fine. I have 2 environments for testing this and both fail the same way.  It seems to be an issue with ConfigMgr not deleting old sender addresses and then when the same FQDN is used it fails to synchronize with the secondary sites.  DP's that were installed only once continue to work fine and their addresses are able to synchronize fine everytime a change is made to rate limits or schedules.

I'm putting in a call with MS soon but wanted to put this on the forum to see if anyone else has seen this and has a solution.

Environment 1: CAS-Pri-Sec

Server: 2008 R2

Remote SQL: 2008 R2 ver 10.53.6000.34

Secondary sites have full SQL not express (corp policy)

ConfigMgr R2 CU4

Environment 2: CAS-Pri-Sec

Server 2012 R2

Remote SQL: 2012 ver11.2.5058.0

Secondary sites have full SQL not express using,  MP replica to primary(corp policy)

ConfigMgr 2012 R2 CU1

When looking at replication links all are green and no errors in rcmctrl.log file.  Run the link analyzer between primary and secondary and shows an error with SC_Adress table. Query the databases in SQL and you can see the difference.  When I let RLA reinitialiaze the tables both databases then match but pkgXfermgr.log file starts to throw errors stating sender address not found.

pkgXfermgr.log:

Sending thread starting for Job: 131, package: CAS00091, Version: 1, Priority: 2, server: xxxxxx, DPPriority: 200  $$<SMS_PACKAGE_TRANSFER_MANAGER><02-20-2015 08:05:27.364+300><thread=6924 (0x1B0C)>

~Server name is empty in address.  $$<SMS_PACKAGE_TRANSFER_MANAGER><02-20-2015 08:05:32.411+300><thread=6924 (0x1B0C)>

STATMSG: ID=8201 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_PACKAGE_TRANSFER_MANAGER" SYS=yyyyyy SITE=S01 PID=2368 TID=6924 GMTDATE=Fri Feb 20 13:05:32.411 2015 ISTR0="." ISTR1="" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=2 AID0=400 AVAL0="CAS00091" AID1=404 AVAL1="["Display=\\xxxxxx\"]MSWNET:["SMS_SITE=S01"]\\xxxxxx\"  $$<SMS_PACKAGE_TRANSFER_MANAGER><02-20-2015 08:05:32.411+300><thread=6924 (0x1B0C)>

~Couldn't parse the address.  $$<SMS_PACKAGE_TRANSFER_MANAGER><02-20-2015 08:05:32.413+300><thread=6924 (0x1B0C)>

~Attempt to connect failed.   $$<SMS_PACKAGE_TRANSFER_MANAGER><02-20-2015 08:05:32.413+300><thread=6924 (0x1B0C)>

~Restart time = 2/20/2015 8:14:32 AM Eastern Standard Time  $$<SMS_PACKAGE_TRANSFER_MANAGER><02-20-2015 08:05:32.413+300><thread=6924 (0x1B0C)>

February 20th, 2015 7:36pm

Hi,

Have you tried using Hierarchy Maintenance tool to troubleshoot this issue.

Technical Reference for the Hierarchy Maintenance Tool (Preinst.exe) in Configuration Manager

https://technet.microsoft.com/en-us/library/hh847647.aspx

Free Windows Admin Tool Kit Click here and download it now
March 6th, 2015 3:11am

Microsoft will be accepting this as a bug.  Please call MS support if you encounter this issue and they can provide instructions on a workaround to force secondary site to synchronize.
  • Marked as answer by Nixapatfan 17 hours 50 minutes ago
April 3rd, 2015 9:55am

Microsoft will be accepting this as a bug.  Please call MS support if you encounter this issue and they can provide instructions on a workaround to force secondary site to synchronize.
  • Marked as answer by Nixapatfan Friday, April 03, 2015 1:52 PM
Free Windows Admin Tool Kit Click here and download it now
April 3rd, 2015 1:52pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics