locked
ADR hell RRS feed

  • Question

  • I have been working with ADRs and they seem to be rather temperamental.  I am running into problems where one of them that I had quit working properly, so I created a new one.  When I did, I told it to put the updates in a specific folder (a new one that had not yet been created) and I had to identify the path to that folder.  Well when I entered the path, I didn't include the folder in the path because it was new (so it hadn't been created yet) and it was listed at the top as to the name of the folder.  My logic was that if I included it, it would create the following file structure to house the updates:  \\server\share\share\folder\folder.  Well it didn't do that.  It put the updates in \\server\share\share, so it was kind of a mess.  So what I did was removed the updates, then deleted the ADR, created a new one with that correction and re-ran it so it would download the updates.  So now in the component status\sms_distribution_manager I am getting mondo errors.  It is looking for those updates in the \\server\share\share, but they aren't there since I deleted them.  So how do I correct this?  I have tried removing this from the DPs but that option is not available.  I also noticed that the repository for the ADR updates have other folders that disappear when previous ADRs are deleted and in some cases this causes a problem because somewhere something is looking for the updates and I run into the issue all over again.  I had to restore one of these folders from a backup a while back to correct this with a previous outdated ADR and I suspect this will happen again because I am still rolling out DPs and will need to update the ADRs to incorporate the new DPs.  Unfortunately there doesn't seem to be a way to include new DPs into the ADR, so the ADR has to be recreated.  Does anyone have any options on how to best handle ADR management?  It's starting to get really ugly.  Thank you.
    Thursday, February 14, 2013 4:59 PM

Answers

  • Remember, ADRs are just rules, they aren't the updates, updates and update deployments themselves. ADRs simply create or update these other objects on a periodic basis. Once these other objects are created, the ADR plays no part.

    For your first issue (with the folder pathing), sorry to be blunt, but that's what you get for assuming. That path is used for the source directory of an update package which you need to go and clean up. However, once an update (or set of updates) is added to an update package, that package will automatically be updated on the DPs it is assigned to. There is no (supported) way to stop this even if you delete the update package -- you just have to let it run its course (which could take a while since that package has a lot of extra "stuff" in it).

    As for adding DPs, as mentioned, the ADR has no real functional part, it is simply creating other objects that do the work. Thus, you need to go to the update package created/updated by the ADR and add the DP there.


    Jason | http://blog.configmgrftw.com

    Thursday, February 14, 2013 6:45 PM

All replies

  • Remember, ADRs are just rules, they aren't the updates, updates and update deployments themselves. ADRs simply create or update these other objects on a periodic basis. Once these other objects are created, the ADR plays no part.

    For your first issue (with the folder pathing), sorry to be blunt, but that's what you get for assuming. That path is used for the source directory of an update package which you need to go and clean up. However, once an update (or set of updates) is added to an update package, that package will automatically be updated on the DPs it is assigned to. There is no (supported) way to stop this even if you delete the update package -- you just have to let it run its course (which could take a while since that package has a lot of extra "stuff" in it).

    As for adding DPs, as mentioned, the ADR has no real functional part, it is simply creating other objects that do the work. Thus, you need to go to the update package created/updated by the ADR and add the DP there.


    Jason | http://blog.configmgrftw.com

    Thursday, February 14, 2013 6:45 PM
  • Thank you for your response.  Yes, I do realize ADRs are just rules, but I am trying to find the best way to utilize them in a new environment.  I am faced with a bit of a learning curve here, since I am coming from sms 2003 instead of sccm 2007 and my experience with wsus is limited to what I am currently in the process of learning with sccm 2012, which is a challenge at best, especially since I need to train other people and I am trying to utilize ADRs to everyone's advantage so they don't have to worry about manual downloads.  So I am bound to make a mistake or two when trying to determine whether I should bear right or left when going through a configuration wizard that I have utilized fewer rather than more times (I wasn't making assumptions, I was having to make a decision and seeing what resulted in that decision and when I made the wrong decision I had to step through the process again to correct it).  As a result I had two deployments, so I did manage to correct the problem by deleting the incorrect deployment.  The other deployment has all the same updates in it and they also reside in the folder to who's path I directed.  That is good information to have regarding updating the package itself with the new DPs.  So I guess I have a choice when I get my the rest of my DPs installed.  It is a matter of either going to all the pre-existing packages and adding the new DPs, or recreating the ADR when the time comes so it already knows what DPs are in the environment to which the packages need to point.  Thank you again for your help.
    Thursday, February 14, 2013 9:00 PM
  • I actually stopped using ADRs.  I know SP1 brought out the new monthly update template even, but I still prefer to build out my own.  I can create software update groups with very specific updates in them and ensure I am deploying the same exact updates to both Dev and Prod each month.  After sync I pick all the updates I want under All Software Updates, Send them to a Software Update Group, and then deploy that group to the desired collections.
    Sunday, February 17, 2013 1:57 AM