Can I ask what sort of package has 100K+ files? My installation of Windows 8.1 Update with all my software installed has 159,669 files or there about’ s.
It must be a pretty serious piece of kit ☺ From: [email protected] [mailto:[email protected]] On Behalf Of elsalvoz Sent: Friday, 23 May 2014 2:07 AM To: [email protected] Subject: Re: [mssms] RE: Need to fact check some things 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]<mailto:[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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Krueger, Jeff Sent: 21 May 2014 17:36 To: [email protected]<mailto:[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<http://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<http://PrimarySite.corp.my.company.com>> to <PrimarySite.corp.my.company.com<http://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<http://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<http://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<http://PrimarySite.corp.my.company.com>> to <PrimarySite.corp.my.company.com<http://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<http://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<http://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. ________________________________ CONFIDENTIALITY NOTICE AND DISCLAIMER The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission.
