What's new
Forums on Intune, SCCM, and Windows 11

Welcome to the forums. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your topics and posts, as well as connect with other members through your own private inbox!

SOLVED Slow content distribution to DP's since 1810 update

  • Thread starter Thread starter AlTu
  • Start date Start date
  • Replies Replies 17
  • Views Views 17K
A

AlTu

Active Member
Messages
37
Solutions
1
Reaction score
5
Points
8
Hi,

Couple of days ago I've upgraded my prod environment to 1810. Everything was smooth and all is working fine.

However, there is one thing that starts to bother me a lot.

Content Distribution to all my DP's is taking a couple of hours where it took a couple of minutes in the past.
It is normal that it takes long to some remote DP's. But it's taking hours for all of them. Even those located in HQ.

A small package of 10MB took a minute or two in the past to be fully processed and now it takes a couple of hours.

As an example, some package are still synchronizing since yesterday.

I have no bandwidth limitations on any DP.
The thing is... eventually it works fine. But it just takes very long.

It worked perfectly fine for years. Never had any issues with it.
Any idea how to start troubleshooting this?

In the PkgXferMgr.log file this keeps coming back:
Yield 5 seconds due to bandwidth control, the current sending rate is 50 percent

But I have no limits on my DP's?
Is there another place this is configured other than the DP "Properties\Rate Limits"
 
Sort by date Sort by votes
I think the only place to limit the bandwidth used by DP is "Properties\Rate Limits".
If you are using a distribution point group, check their properties too.
 
Upvote 0 Downvote
Youssef Saad said:
I think the only place to limit the bandwidth used by DP is "Properties\Rate Limits".
If you are using a distribution point group, check their properties too.
Click to expand...

Well, that's what I thought.
I have none set, except for one DP.
But it's required on that particular DP.

If you run this query on the SQL Server it will show you if any DP has bandwidth throttling:
SQL: 
Select * From SC_Address

I'm not sure which options you referring to in the DP Group properties?
I don't think there are any bandwidth settings in the DP Group properties.
 
Upvote 0 Downvote
Having similar issues since deploying 1810... content distribution and clients discovering new apps is taking exponentially longer then before. It's very frustrating.
 
Upvote 0 Downvote
Daptonic said:
Having similar issues since deploying 1810... content distribution and clients discovering new apps is taking exponentially longer then before. It's very frustrating.
Click to expand...

That is so frustrating. I'm noticing the same issues.
I can't seem to find any solution for it.
 
Upvote 0 Downvote
AlTu said:
Hi,

Couple of days ago I've upgraded my prod environment to 1810. Everything was smooth and all is working fine.

However, there is one thing that starts to bother me a lot.

Content Distribution to all my DP's is taking a couple of hours where it took a couple of minutes in the past.
It is normal that it takes long to some remote DP's. But it's taking hours for all of them. Even those located in HQ.

A small package of 10MB took a minute or two in the past to be fully processed and now it takes a couple of hours.

As an example, some package are still synchronizing since yesterday.

I have no bandwidth limitations on any DP.
The thing is... eventually it works fine. But it just takes very long.

It worked perfectly fine for years. Never had any issues with it.
Any idea how to start troubleshooting this?

In the PkgXferMgr.log file this keeps coming back:
Yield 5 seconds due to bandwidth control, the current sending rate is 50 percent

But I have no limits on my DP's?
Is there another place this is configured other than the DP "Properties\Rate Limits"
Click to expand...
What kind of environment do you have, CAS, Primary, Secondaries. Can you zip and send me the log files - Sender.log, despooler.log, distmgr.log and pkgxfer.log from the site server via contact form.
 
Upvote 0 Downvote
In my case, the issue was in the Database. Per the MS Engineer, there were some left over tasks that were flooding the smsdbmon.log file. Since those tasks have been removed, everything is working much better.

I'm awaiting the full write up, once I get that I'll try to provide more details where possible.
 
Upvote 0 Downvote
Here is the write up from MS Support ... hope this helps someone else.

------

we sent a test package at 1:32pm, but distmgr didn't process it for another 20 minutes

This was because smsdbmon log was just full of tons of these errors every second

01-18-2019 13:53:44.975 SMS_DATABASE_NOTIFICATION_MONITOR 8388 (0x20c4) WARNING: Unable to send update on component PolicyTargetEvalNotify_iud
01-18-2019 13:53:44.975 SMS_DATABASE_NOTIFICATION_MONITOR 8388 (0x20c4) WARNING: Unable to send update on component PolicyTargetEvalNotify_iud
01-18-2019 13:53:44.975 SMS_DATABASE_NOTIFICATION_MONITOR 8388 (0x20c4) WARNING: Unable to send update on component PolicyTargetEvalNotify_iud
01-18-2019 13:53:44.975 SMS_DATABASE_NOTIFICATION_MONITOR 8388 (0x20c4) WARNING: Unable to send update on component PolicyTargetEvalNotify_iud
01-18-2019 13:53:44.975 SMS_DATABASE_NOTIFICATION_MONITOR 8388 (0x20c4) WARNING: Unable to send update on component PolicyTargetEvalNotify_iud
01-18-2019 13:53:44.975 SMS_DATABASE_NOTIFICATION_MONITOR 8388 (0x20c4) WARNING: Unable to send update on component PolicyTargetEvalNotify_iud
01-18-2019 13:53:44.975 SMS_DATABASE_NOTIFICATION_MONITOR 8388 (0x20c4) WARNING: Unable to send update on component PolicyTargetEvalNotify_iud
01-18-2019 13:53:44.975 SMS_DATABASE_NOTIFICATION_MONITOR 8388 (0x20c4) WARNING: Unable to send update on component PolicyTargetEvalNotify_iud
01-18-2019 13:53:44.975 SMS_DATABASE_NOTIFICATION_MONITOR 8388 (0x20c4) WARNING: Unable to send update on component PolicyTargetEvalNotify_iud

The triggers listed below are the following ones that we needed to delete

Collections_L table:
SMSDBMON_Collections_L_PolicyTargetEvalNotify_iud_ins
SMSDBMON_Collections_L_PolicyTargetEvalNotify_iud_upd]

Collection_MemberChg_Notif:
SMSDBMON_Collection_MemberChg_Notif_PolicyTargetEvalNotify_ColMember_iu_ins
SMSDBMON_Collection_MemberChg_Notif_PolicyTargetEvalNotify_ColMember_iu_upd

PolicyAssignmentChg_notify:
SMSDBMON_PolicyAssignmentChg_Notify_PolicyAssignmentChg_Notify_iu_ins
SMSDBMON_PolicyAssignmentChg_Notify_PolicyAssignmentChg_Notify_iu_upd

We also checked registry under HKLM/Software/Microsoft/SMS/Triggers to see if there were any related entries to the triggers we wanted to delete, but there were not

So once these were deleted, we created a new package and did a distribution and it finished in under a minute, success!
 
Last edited:
Upvote 0 Downvote
Daptonic said:
In my case, the issue was in the Database. Per the MS Engineer, there were some left over tasks that were flooding the smsdbmon.log file. Since those tasks have been removed, everything is working much better.

I'm awaiting the full write up, once I get that I'll try to provide more details where possible.
Click to expand...

Hello Daptonic,

I am experiencing the same issue after upgrading to CB1810 yesterday. Did you receive the full write up from MS Premier yet?
 
Upvote 0 Downvote
I posted a write up, but it is sitting in a Moderation queue. I'll PM it to you.

or not ... I don't appear to have the rights to do that either lol
 
Upvote 0 Downvote
Hello,

We have been having the same problem with our DP. It takes up to 24 hours for files to come down to the DP's and these files are not big files. We are talking say script that is approx 10k. The only way we can possibly accelerate the process is to restart the SCCM Services. We are running version 5.00.9068.1000. Waiting 24 hours isn't an option and having to restart services any time we update a package isn't feasible either. Any help would be appreciated.
 
Upvote 0 Downvote
rankinf said:
Hello,

We have been having the same problem with our DP. It takes up to 24 hours for files to come down to the DP's and these files are not big files. We are talking say script that is approx 10k. The only way we can possibly accelerate the process is to restart the SCCM Services. We are running version 5.00.9068.1000. Waiting 24 hours isn't an option and having to restart services any time we update a package isn't feasible either. Any help would be appreciated.
Click to expand...
Hi Rankinf,
As I remember the problem in ny case was an error in the particular update. The update made all our 12000 client update at once even though configuration was set to use 7 days. Our MP’s got overloadet and therefore it took long time to update distribution points.
 
Upvote 0 Downvote
Hello,

Well, we only have one DP for the college as we only image machines as needed and update the images as software's need to be patched. This is why its confusing that it is taking 24 hours to just push a single update to the single DP. Further more, the DP is the SCCM server itself.
 
Upvote 0 Downvote
You must log in or register to reply here.

Similar threads

  • PENDING MECM cannot access to WSUS WID
  • PENDING Intune Expedite Update policy missing KB5077744 OOB update
  • PENDING KB5077744 update deployment via SCCM
  • Service Connection Tool improvements in SCCM 2509
  • PENDING Distribution Manager failed to access the source directory

    • Forum statistics

    Threads
    7,164
    Messages
    27,964
    Members
    18,258
    Latest member
    RETAL

    Latest posts

    Trending content
    Back
    Top