We ran into similar situation with failed packages, we do not have secondaries, though, is a similar behavior. After working with MS 3rd level escalation support for a long time, a couple of bugs were filed regarding status message not displaying the correct status on the console. it may be the same issue with secondaries and certain packages.
Some history. We have a couple very large packages with over 100k+ files in it, this packages kept failing so we kept distributing to our slow link remote DPs globally in asia pacific to be exact. The problem is that even though the packages were in progress due to scheduled retry interval, the console continue to display as failed. The only way to verify that there is an active job for those packages is with DP job manager and pckxfermgr.log. This behavior is displayed whenever there is a failure or manually distributing and canceling a package. We have been working on this issue with MS for a long time. Another issue that I've noticed is that packages stay in "Content Monitoring" status for ever, this is found if you query the database V_pacakgeStatusDistPoinsSumm and v_packages jointly. I created a powershell script to monitor packages status from the DB directly and get active packages status. (contact me offline if anyone is interested on the script) Another tip for everyone distributing large packages with thousands of files, "turn SCCM built-in back job "off". backup stops the SMSEXEC and every single package actively being deployed and restarts it from 0 when resumed, nice right? SQL backup is sufficient for DR. On Thu, May 22, 2014 at 12:23 AM, Andrew Craig <[email protected]>wrote: > 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 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. > > > >
