l.hv.yang

I run the cleanup monthly and have no issues with SUP breaking. So far so good.

OK! did some more digging around. turns out the management point server had the wrong subnet mask entered into it's IPconfig....problem solved!

Did a little bit more investigating: This is a screenshot of ProcessMonitor.exe, from a DP that is able to send smsdpusage.log to the MP: "Source --> Destination" This is a screenshot of ProcessMonitor.exe from the troubled DP. TCP Reconnect eventually times out.

Hi Peter, from what I can tell, other messages get processed fine. If i distribute content to this server, success messages are sent perfectly. Is there something else I should be looking at as far as status messages? This server's only role is to be a DP..nothing else. Thanks for your time!

Does everything else distribute ok?

Hi everyone. I'm running Configmgr 2012 R2 and noticed that 1 of my DPs has errors sending DP usage to the site server. My two other DPs have no issues sending usage reports. Have you guys run into this issue? I have uninstalled and reinstalled the DP role and reconfigured IIS, but no luck on correcting the errors.

Aquintus, where did you go to find those ini files? \SCCMContentlib\pkglib ??

These helped me tremendously. Thank you so much.

"Enable Software Updates on Clients" is set to "Yes" in "Default Client Settings?"

I ran into something similar, but had to add the actual Distribution Points to the custom security scope, for application deployment.

I ran into something similar to this yesterday when a user was trying to deploy an application, using a New Security Role I had created (very limited applications and collections visible to user). There were no distribution points available for the user at the "Specify the Content Destination" screen. After poking around with Security Roles permissions, i realized that the Distribution Points needed to be added to the Security Scope. After doing that, the user was able to deploy the application successfully.

In my experience, i find that restarting the SMSAgentHost Service and Windows Update service will speed things up.

I've sifted through my discovery logs and notice that this "CI" domain is being picked up during user group discovery. It looks like it's picking up the first string of the fqdn and not the netbios domain name. Any tips?

You can transfer the SCCMcontentlib folder to a different drive to free up space: http://blogs.technet.com/b/neilp/archive/2013/01/08/configuration-manager-2012-sp1-content-library-transfer.aspx From what you posted, it appears deleting packages had no affect on the C: drive? Is there another SCCMContentlib folder on your server (D: ? E: ? , etc..) ?

heh, i ran into the same situation in my test lab. :-) simple mistake caused hours of troubleshooting!