Looks like forest discovery is 1 week. System discovery is actually disabled. User discovery is 1 day with delta of 5 minutes.
We reused the AD objects during our Win7 migration and didn’t have any issues. I think there was one case where the machine object was in an AD group for XP machines only and it caused a minor issue once the machine was Win7. We don’t really have many OS specific GPOs and do not do a lot of machine based AD groups though. Daniel Ratliff From: [email protected] [mailto:[email protected]] On Behalf Of Corkill, Daniel Sent: Sunday, April 12, 2015 8:56 PM To: [email protected] Subject: RE: [mssms] AD group delta discovery not working on OSD refresh No reason I couldn’t do that, I just have group full discovery running every 7 days because it’s default. Just out of curiosity what do you have your forest, system and user discoveries set at for their full scans (assuming you use them), mine are all set at 7 days. Is there any issue with “reusing” AD objects during OSD refreshes? Daniel. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Daniel Ratliff Sent: Monday, 13 April 2015 10:42 AM To: '[email protected]'; '[email protected]' Subject: RE: [mssms] AD group delta discovery not working on OSD refresh We had similar issues with AD groups and users. We just had our full discovery run nightly, and we were okay with 'next day' delivery. I assume that will not work for you? -----Original Message----- From: Corkill, Daniel [[email protected]<mailto:[email protected]>] Sent: Sunday, April 12, 2015 08:24 PM Eastern Standard Time To: [email protected]<mailto:[email protected]> Subject: [mssms] AD group delta discovery not working on OSD refresh All, We’ve had reports recently of machines being refreshed and the security groups the AD object is in not making its way into ConfigMgr. It’s important that this happens as we use queries on a bunch of application deployment collections to populate the membership. I was reading the following article http://blogs.technet.com/b/configurationmgr/archive/2012/03/27/machine-added-to-a-configmgr-group-is-not-captured-during-the-delta-discovery-process.aspx and I’m thinking the case here is that because the AD object is being reused during the OSD refresh and the membership hasn’t changed the usnChanged attribute hasn’t been updated so it’s not being picked up during the delta discovery. Is there a best practice I should be following – something along the lines of deleting the AD object before the OSD refresh? If that’s the case is there a scripted way to perform this during the task sequence – I’m thinking in such a circumstance I’d need to programmatically inventory the groups and re-add the AD object to them once it’s recreated also. Daniel. ********************************************************************* This email, including any attachment, is confidential to the intended recipient. It may also be privileged and may be subject to copyright. If you have received this email in error, please notify the sender immediately and delete all copies of the email. Any confidentiality or privilege is not waived. Neither the Council nor the sender warrant that this email does not contain any viruses or other unsolicited items. This email is an informal Council communication. The Council only accepts responsibility for information sent under official letterhead and duly signed by, or on behalf of, the Chief Executive Officer. Privacy Collection Notice Logan City Council may collect your personal information, e.g. name, residential address, phone number etc, in order to conduct its business and/or meet its statutory obligations. The information will only be accessed by employees and/or Councillors of Logan City Council for Council business related activities only. If your personal information will be passed onto a third party, Council will advise you of this disclosure, the purpose of the disclosure and reason why. Your information will not be given to any other person or agency unless you have given us permission or we are required by law. The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. ********************************************************************* This email, including any attachment, is confidential to the intended recipient. It may also be privileged and may be subject to copyright. If you have received this email in error, please notify the sender immediately and delete all copies of the email. Any confidentiality or privilege is not waived. Neither the Council nor the sender warrant that this email does not contain any viruses or other unsolicited items. This email is an informal Council communication. The Council only accepts responsibility for information sent under official letterhead and duly signed by, or on behalf of, the Chief Executive Officer. Privacy Collection Notice Logan City Council may collect your personal information, e.g. name, residential address, phone number etc, in order to conduct its business and/or meet its statutory obligations. The information will only be accessed by employees and/or Councillors of Logan City Council for Council business related activities only. If your personal information will be passed onto a third party, Council will advise you of this disclosure, the purpose of the disclosure and reason why. Your information will not be given to any other person or agency unless you have given us permission or we are required by law. The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
