Hi There; I was wondering if anyone has ADDD working in R3 yet? I'm having issues and wondered if anyone has seen this yet? I have a Activbe Directory Global Sec group called 'Bob' (for testing), and have enabled ADDD with the default times in all 4 AD discovery methods; From the Site Status, it looks like ADDD is taking place successfully every 5 mins (no errors when crating DDR's). In SCCM I have my 'Bob' collection (which picks up changes to System objects as the security group contains Computer objects): select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.SystemGroupName = "RSC\\Bob" I have 'Dynamically add new resources' ticked in the collection. The issue is; any additions or deletions from the security group is not being reflected in the collection; even when 'Update Collection Membership' is pressed; I figured that I would be looking at max 5+5 mins. for an update but 2 hours later and lots of test changes to the group nothing has happened. Please can anyone point me in the right direction with this?:-)

"member of" is not a real attribute of objects in Active Directory; it is a "back link" attribute that is not populated like normal attributes (http://technet.microsoft.com/en-us/library/cc961761.aspx). That's why System Group Discovery is needed at all, it can't simply query this attribute to determine an object's group memberships, thus determining deltas is quite a bit more difficult than other simple attribute changes. Not saying that this wouldn't be valuable, just saying it's a lot more complex than your statement above implies.Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys

Hi. I know this is not the solution to the question. But isn´t this, user self service, going to be "solved" in v.Next by the approval process in the new client ? Rgds Thomas

( The security group that contains computer objects, according to the discovery methods 'memberof' is only collected for 'users' and not systems - surly the membership of a group that contains objects should be picked up during delta discovery. So background on our company - we was using LANdesk for software and after 2 years of jumping up and down, we agree to put in SCCM; now I find that it takes 24 hours for a user to get a piece of software where with LANDesk it takes all of 30 seconds to push software out. Lowering peoples expectations of ICT is not really an answer that anyone should find acceptable; neither really is buying another piece of software for self-service where SCCM should be end-to-end. Anyway, you mentioned that memberof (if this is the attribute that is used to collect group membership for systems) does not trigger on delta discovery - but could we trigger the delta another way? Maybe crafting a new attribute and timestamping it each time via a script? Is this worth investigating? I don't think SCCM has been designed for use with AD given the long refreshes between group updates, the issue with collections is that when I delete a PC from all Systems (say for re-imaging for another user) I really cannot expect someone to go though 30 odd collections and delete direct memberships; I have been looking for scripts that can go into SCCM and delete all direct memberships given a specific PC name - but I cannot find one! ; does anyone know if such a thing exists? Yours in anguish, Mr. Flubalub.:-)

There is an option for removing direct membership available at http://www.deploymenttech.com/index.php?option=com_content&view=article&id=238:nesting-task-sequences&catid=34:blog&Itemid=1. I have not used it but be worth testing to see if it helps. I haven't installed R3 yet and generally it seems to give some nice features but if other people are correct in describing the limitations of delta discovery for Active Directory System Group Discovery, it kinda makes you wonder what significant benefit is offered by having the option at all. For Software Distribution, the main reason for having Active Directory System Group Discovery is to detect changes that Active Directory System discovery does not capture (e.g. group memberships), if delta discovery does not cover this then its value (as a configurable option for Active Directory System Group Discovery) seems pretty questionable.

We have the same issue in that previous software push technologies provided the instant gratification to our clients. Unfortunately, I sense that some prevailing thought is to let the end-clients suffer a psuedo-withdrawal and eventually they'll get over their instant gratification needs; obviously, it may be that some have never directly answered support calls which allows the more theoretical answer than one based in reality. Having said all of that nonsense, we have implemented something like this that will hopefully keep the masses happy, and us employed... We sequence in all of our core applications during OSD; these are common to all workstations While awaiting SCCM 2012 (to become more user vs. device centric), we have a separate AppV server providing user-centric / on-demand application delivery for those applications suitable for such deployment. While AppV is supported directly in current SCCM offerings, you loose the on-demand capabilities of AppV...hence our hope rests with the merging of both worlds with SCCM 2012... The remaining are pushed through AD group discovery and subsequent SCCM advertisement delivery. Like you indicated, this grouping should represent a small subset of the total demand. In concert with this is the use of SCUP to automatically roll updates not provided within the WSUS framework (i.e. from non-MS vendors); the latter is still WIP. Regards.