I had a (very) similar problem on 2007, and MCS couldn't help. I ended up redistributing all the packages that were stuck with a false status. But I had to update each package 5 times before the distmgr finally caught up with itself. Took a long time but it was the only reliable way to fix it. (on 2007). I created a bespoke script that did this for me.
I don't believe the MP is the problem if you are able to distribute new packages. Sounds like it is backed up with traffic. Did you have a problem originally with a distribution that got cancelled or filled up the target disk or lost site communication in the middle of transfer...? You're on 2012 because you mentioned Validation. If you are having these problems then I would absolutely turn that off for now. Also turn down the retry intervals (make sure they are not set to retry 100 times). It is difficult to read any inbox data for distmgr/despoolr/pkgxfermanager because, especially for you, they will be going through pretty quick. Anyway I recommend not touching and certainly not deleting anything from there. There is information in WMI and SQL on content distribution status, but again, don't delete anything from there. Here some WMI classes to query: SMS_DistributionPoint SMS_DPStatusInfo SMS_PackageStatusRootSummarizer SMS_DistributionJob SMS_DistributionPointGroup and SQL select * from ContentDistribution select * from ContentDistributionByPkg select * from ContentDPMap select * from DistributionContentVersion select * from DistributionJobs select * from PkgServers How many packages are in a false status, or not updating status? Can you try the following: Pick 1 package Set distribution priority to high Redistribute content Check the distmgr log files on both servers Wait until distmgr notices the package update request, it might say it doesn't need to update Redistribute again (do this 4 or 5 times, in between waiting for distmgr to finish) At the fourth or fifth attempt you should see something a lot more substantial in the distmgr log, if so great Wait for console refresh and hopefully the package is now ok Set distribution priority back to medium In 2007 content distribution goes something like this: Source --> SMSProv --> distmgr -->Secondary Site? --> compress --> send compressed package to secondary --> despool --> distmgr --> status to primary site In 2012 global and site content is replicated via SQL Broker but Content still uses file replication. It is handled slightly differently, due to the new Content Library but essential PKGXferMgr will still compress and send. You could also look at prestaging the content, but I would try to fix the existing distributions before adding any other variables to the mix. I hope this helps, Andrew From: [email protected] [mailto:[email protected]] On Behalf Of Krueger, Jeff Sent: 21 May 2014 17:36 To: [email protected] Subject: [mssms] Need to fact check some things Sorry this is going to be a longer one, but I've been dealing with a support case for some issues with content distribution that is stuck at an in progress status on some DPs on secondary sites. The support engineer that I've been working with has suggested that our secondary site server is having issues sending status messages about content distribution to the primary site server because it is supposedly trying to talk to the internet based MP. He's saying this based on the ClientLocation.log entries as shown below. I read the log and see that it is assigned to the MP off the primary site server, it is getting a local and proxy mp of the secondary site server (which is itself) and though it is enumerating the MP that it would have if it were on the internet it is not getting assigned to it. Also the support engineer has said that the system is too busy processing status messages and they they're backed up and that's why those packages are stuck as in progress. Though there is no problem with new content getting distributed just a large group that are stuck on 4 server as in progress, new packages go to these same servers with no issues. Where would I find any backed up status messages besides the inboxes? The support engineer queried WMI for status messages per DP and said that all the results returned are unprocessed. Is this accurate? Where else can I check for unprocessed status messages? Inboxes on the primary are not backed up, database replication links are good. A suggestion was made to turn off content validation as that would help the status messages to process faster >From ClientLocation.log on secondary site server Domain joined client is in Intranet ClientLocation 5/20/2014 6:08:16 PM 5804 (0x16AC) Rotating assigned management point, new management point [1] is: PrimarySite.corp.my.company.com (7958) with capabilities: <Capabilities SchemaVersion="1.0"><Property Name="SSLState" Value="0"/></Capabilities> ClientLocation 5/20/2014 6:08:16 PM 5804 (0x16AC) Assigned MP changed from <PrimarySite.corp.my.company.com> to <PrimarySite.corp.my.company.com>. ClientLocation 5/20/2014 6:08:16 PM 5804 (0x16AC) Rotating internet management point, new management point [1] is: ConfigMgr.company.com (0) with capabilities: <Capabilities SchemaVersion ="1.0"><Property Name="SSL" Version="1" /></Capabilities> ClientLocation 5/20/2014 6:08:17 PM 5804 (0x16AC) Rotating assigned management point, new management point [1] is: PrimarySite.corp.my.company.com (7958) with capabilities: <Capabilities SchemaVersion="1.0"><Property Name="SSLState" Value="0"/></Capabilities> ClientLocation 5/20/2014 6:08:17 PM 5804 (0x16AC) Assigned MP changed from <PrimarySite.corp.my.company.com> to <PrimarySite.corp.my.company.com>. ClientLocation 5/20/2014 6:08:17 PM 5804 (0x16AC) Rotating proxy management point, new management point [1] is: SecondarySite.corp.my.company.com (7958) with capabilities: <Capabilities SchemaVersion="1.0"><Property Name="SSLState" Value="0"/></Capabilities> ClientLocation 5/20/2014 6:08:18 PM 5804 (0x16AC) Rotating local management point, new management point [1] is: SecondarySite.corp.my.company.com (7958) with capabilities: <Capabilities SchemaVersion="1.0"><Property Name="SSLState" Value="0"/></Capabilities> ClientLocation 5/20/2014 6:08:18 PM 5804 (0x16AC) Thanks -Jeff ________________________________ CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed. If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by reply email, delete the email from your computer system and shred any paper copies. Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. See our Privacy & Security page on www.henryford.com<http://www.henryford.com> for more detailed information as well as information concerning MyChart, our new patient portal. If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us.
