yep. That's the down side. Except where I also had All DP's assigned. Then I was OK. Or make a new DP just like the old and assign it first. Just a thought.
Dave On Tue, Feb 17, 2015 at 2:19 PM, Sean Pomeroy <[email protected]> wrote: > If you remove the DP group from a package, won't it start to remove the > content from all those DPs? > > On Tue Feb 17 2015 at 2:16:26 PM Ryan <[email protected]> wrote: > >> Someone could probably script that... >> >> On Tue, Feb 17, 2015 at 12:21 PM, David Jones <[email protected]> >> wrote: >> >>> No I definitely don't want to edit the database without MS helping but I >>> just found a way to get it fixed. It will be labor intensive but doable. >>> >>> Look in Database views for v_DPGroupMembers. Find a server, DPNALPath, >>> that is in your DP group and determine the DP GroupID from that. If the >>> server is in more than one DP Group then you will have to count the >>> instances of the GroupID to find the one with the right number of servers >>> for the DP Group you are interested in. All of my DP's are in 2 Groups, All >>> DP's and DP's of the agency that the server is located in. So one will have >>> far more instances of GroupID than the other. >>> >>> Take that GroupID and find the view v_DPGroupContentDetails. Right >>> click the view and choose Select Top 1000 Rows. After the last line of >>> query at the top add: where GroupID = >>> '{AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE}' . Use single quotes and keep the >>> {} brackets. >>> >>> In the result I am finding something like this: >>> >>> There are 19 servers in this DP group. Note that some packages show 20 >>> or 21 servers and have a stuck status of In Progress or Error. I am going >>> to each package, removing the DP Group, waiting a few minutes and then >>> putting it back. So far so good. And I am doing NO editing of the >>> database. This will take a few days. >>> >>> [image: Inline image 2] >>> >>> Dave >>> >>> >>> On Tue, Feb 17, 2015 at 12:45 PM, elsalvoz <[email protected]> wrote: >>> >> +1 >>>> >>>> True/false on status all the time. Don't trust them as your environment >>>> health view for distribution. >>>> >>>> Cesar >>>> On Feb 17, 2015 8:52 AM, "Nash Pherson" <[email protected]> wrote: >>>> >>>>> I think the best thing to do in these scenarios is open a support >>>>> case with Microsoft. There are a bunch of bugs in those health status >>>>> views >>>>> which require going into the database to clean up records. (And the more >>>>> of us that call and open tickets, the more likely it is that they will fix >>>>> the bugs.) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Nash >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* [email protected] [mailto: >>>>> [email protected]] *On Behalf Of *David Jones >>>>> *Sent:* Tuesday, February 17, 2015 8:48 AM >>>>> *To:* [email protected] >>>>> *Subject:* [mssms] "Distribution Point Group Status" in SCCM 2012 R2 >>>>> CU4 Console >>>>> >>>>> >>>>> >>>>> I have spent the past week getting all of the 'Distribution Point >>>>> Configuration Status' statuses green. Mostly it was ghost packages left >>>>> over from when SCCM 2012 was upgraded from sp1 to R2. But now they are all >>>>> Green. They were all real issues at each DP that had to be cleaned from >>>>> both the WMI and file structure. Luckily there are scripts online and >>>>> the Content Library Explorer that helped find which ones were the >>>>> culprits. >>>>> >>>>> >>>>> >>>>> However, the "Distribution Point Group Status" is another story. Many >>>>> show either Error or In Progress. When you open the 'View Status', nothing >>>>> is under In Progress, Error, or Unknown. So I have nothing to go by to >>>>> help >>>>> me figure out what is hanging these group statuses from showing Success. >>>>> >>>>> >>>>> >>>>> Has anyone dealt with this before? >>>>> >>>>> >>>>> >>>>> Dave >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >
