If you have more than a few distribution points in your ConfigMgr environment, you may wish to ensure that content replication to those servers occurs in a specific order. Distribution Point Priority Manager provides a visual and intuitive interface for granularly controlling this order.
ConfigMgr uses a multi-tiered system for determining the order in which to distribute content. This blog post describes the process in detail. The bottom line is that there are 3 levels of customizable prioritization (the 4th level is based on your actual network performance for each server). The first 2 levels are specific to individual packages/jobs, and they can be managed via the DP Job Manager Tool and the ConfigMgr admin console.
The third level, Distribution Point Priority, allows you to control the order in which servers receive content. By default, all distribution points have a priority of 200. When DPs have the same priority, then ConfigMgr ranks them according to their most recent average transfer rate (this is the 4th level). So, if you just want your content to replicate to fastest links first and slowest links last, you don't need to update these priorities at all. But if you need to prioritize them according to any other factors, Distribution Point Priority is the mechanism.
Unfortunately, Distribution Point Priority is not exposed in any GUI or tool that ships with ConfigMgr. The only way to view/modify these values is via WMI on the site server. If you only need to edit a single value, the blog linked above includes a sample PowerShell script. But I thought, "You know what would be cool? What if you could just reorder these visually by drag and drop?"
So I embarked on a "stretch" project for myself - write a native WPF app in C# to implement a drag and drop interface for re-prioritizing distribution points. I found this awesome sample class for adding drag and drop functionality to a ListView, which made things surprisingly easy. Here's the end result:
It ended up being a really fun project and a great way to dip my toes in the waters of native .NET development with Visual Studio. Maybe it will help some ConfigMgr admins out there, too.
I hope this was helpful. If you have any comments or questions, or if you have an idea about how to further improve this approach, you can connect with me via Twitter.