I had an interesting issue during a migration project from SCCM 2007. After the reassign process, some distribution points were constantly re-importing packages. They were stuck in an importing package loop during distribution point migration

I found this issue when I went to see the configuration status of the distribution points (Monitoring / Distribution Status / Distribution Point Configuration Status)

All problematic Distribution Points were having “pending” tasks even if the reassign process was completed. The DP were functioning correctly and packages that were marked as “Importing” were on the DP.

When looking at distmgr.log I could see the import tasks repeatedly happening.

Importing Package [PackageID][packagePath] into SIS on Distribution point [DPName] STATMSG ID=xxx Source=”SMS Server” Comp=”SMS_Distribution_Manager”

Importing Package Loop during Distribution Point Migration

The .DPU (distribution point upgrade) files were processed correctly, I could see them disappearing from the DistrMgr.box but it was coming back after a couple of hour.

Importing Package Loop during Distribution Point Migration

I decided to compare the properties of my different DP using a quick query in SQL Management Studio.

[pastacode lang=”sql” message=”” highlight=”” provider=”manual” manual=”Select%20DPID%2CServerName%2CDPFlags%20%0AFrom%20DistributionPoints%0Aorder%20by%20DPFlags”/]

I found a correlation between the looking DP and the DPFlags attribute. All the DP that were having a value of 4 were constantly caught in a never ending importing  package loop.

As seen in previous screenshot, DPID 150,151 and 154 has a DPFlags = “4”


Importing Package Loop during Distribution Point Migration

Modifying the value is possible using WMI but since this is unsupported, a call was opened at Microsoft.

This is what they sent.

I don’t recommend playing with this field, I’m providing this procedure as informative only.

How to set DPFlags:
1. Open up an administrative command prompt on ConfigMgr 2012 Primary Site
2. Type wbemtest and hit enter to open up the tool.
3. Click Connect and in the box type root\sms\site_[SITECODE] and click on
Connect again.
4. Click the query button and Enter the following query: select * from
5. In the list that populates, you’ll see entries that begin with
SMS_SCI_SysResUse.FileType=2,ItemName= “[\”Display=\\\\<servername>\\\”]…
The servername highlighted above should match the DP server for which we want
to make that change. Additionally, if you scroll further towards the right,
you’ll find the various roles that are installed on that server listed (each
will be a different line item in the list). You need to choose the one that
says “SMS Distribution Point”.
6. Now, double click on the selected item to open up its properties.
7. In the window that comes up, you’ll have three boxes with the middle one
having the properties. Put a check in Hide System Properties.
8. Scroll down in the list in the middle box and double click on the Property
9. In the Property editor window, click on the button that says View Embedded.
10. Now, there will be a complete list of all the properties of the
Distribution Point, each looking like “SMS_EmbeddedProperty=<no key>”.
11. You will need to find the entry with the PropertyName showing DPFlags by
double clicking each entry. (Don’t save any changes yet)
12. Once you have this entry pulled up, double click on the property called
“Value” and set it to “0” in the window that comes up.
13. Once the above is done, click the Save Property button and then Save Object
in the rest of the dialogs to ensure that the change that was made takes effect.
14. Wait for at least 5 minutes
15. Delete .DPU file for specific DP if exist
16. To take effect you have to restart the “SMSExec” service on the ConfigMgr
2012 Primary Site Server

Importing Package Loop during Distribution Point Migration

Once the service restarted, the DPFlags were set to “0” and the DPU were not see again. I still don’t know what causes this in the first place. All distribution Points were migrated the same way and only a couple had this behavior.

Comments (0)