Michael, Thanks! I will give this a shot. Jeff
On Tue, Jul 29, 2014 at 11:02 AM, Michael Mott <[email protected]> wrote: > Guys, one of our clients had the same issue, I pinged him, hope this > gets thru > > > > *From:* Mitchell, Steven R [mailto:[email protected]] > *Sent:* Tuesday, July 29, 2014 11:56 AM > *To:* Michael Mott > *Subject:* FW: [mssms] SCCM Distribution Point migration issue > > > > Sometimes my emails don’t go through to the list. If you don’t see it > then forward this answer to them. > > > > *From:* Mitchell, Steven R > *Sent:* Tuesday, July 29, 2014 10:51 AM > *To:* [email protected] > *Subject:* RE: [mssms] SCCM Distribution Point migration issue > > Jeff, > > > > I ran into this with my migration. After weeks of this process going on > and on with MS Premiere we found a setting in WMI that resolved this > issue. The way we saw this was through DPU files continuing to show up > meaning that the migration had kicked off again. This is what is > re-evaluating all the software on the migrated DP. > > > > Here are the steps MS sent us. > > > > *How to set DPFlags:* > > 1. Open up an administrative command prompt on ConfigMgr 2012 Primary Site > Server > > 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 > SMS_SCI_SysResUse* > > 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 "Props". > > 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* > > > > I also modified this vbscript to evaluate which dps have the incorrect > setting. WE had hundreds of DP’s so this was helpful as this is a very > manual process. I have attached this script and renamed it to .txt. > > > > Hope this helps you. > > > > STeven > > > > > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Jeff Poling > *Sent:* Tuesday, July 29, 2014 10:13 AM > *To:* [email protected] > *Subject:* Re: [mssms] SCCM Distribution Point migration issue > > > > I can't provide any help other than the fact that I see this in an > environment I migrated as well. If anyone has insight or suggestions, I > would also be grateful! > > > > Thanks, > > > > Jeff > > > > On Tue, Jul 29, 2014 at 10:04 AM, Rick <[email protected]> wrote: > > We are in the process of moving from SCCM 2007 to SCCM 2012 and have > started Distribution Point migrations. SCCM 2012 reported "completed > reassign distribution point" and there were entries in the smsdpprov.log > showing that the packages were migrated. We thought the process had > completed successfully, but soon after, the following entries was written > in the smsdpprov.log for every package: > > *Importing package XXXXXX as content XXXXXX.1 into SIS from source > \\<DPserver>\SMSPKGE$\XXXXXX* > *Failed to access source* > > The "failed to access source" makes sense, since the 2007 package > folder no longer exists because it was migrated and then deleted by the > migration job. This has repeated over and over again (from every few > minutes to 30-60 minute intervals) since the migration job was first run. > The server has been restarted since the migration. It's like the migration > job is running over and over again. > > We are running SCCM 2012 R2 CU1 on Server 2008 R2. > > Any ideas on how to clean this up? Thanks in advance for your assistance. > > > > > > > > > > > ------------------------------ > > > CONFIDENTIALITY NOTICE: This e-mail and any files transmitted with it are > intended solely for the use of the individual or entity to whom they are > addressed and may contain confidential and privileged information protected > by law. If you received this e-mail in error, any review, use, > dissemination, distribution, or copying of the e-mail is strictly > prohibited. Please notify the sender immediately by return e-mail and > delete all copies from your system. > > > ------------------------------ > > > Legal Notice: This email is intended only for the person(s) to whom it is > addressed. If you are not an intended recipient and have received this > message in error, please notify the sender immediately by replying to this > email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This > email and any attachments may be privileged and/or confidential. The > unauthorized use, disclosure, copying or printing of any information it > contains is strictly prohibited. The opinions expressed in this email are > those of the author and do not necessarily represent the views of 1E Ltd. > Nothing in this email will operate to bind 1E to any order or other > contract. >
