This week my post will be about catching Active Directory Group Membership changes. I choose this subject, because I still see and get questions about how long does it take before a group membership change is active in a collection. The short answer would be, based on default settings, between 1 till 10 minutes. In the rest of this post I will show a longer answer on why it’s like that. The main reasons are that the Delta Discovery and the Incremental Updates are working now.
The most important part to quickly catch Active Directory Group Membership changes, is a good configuration. For that two configurations are very important, the Active Directory Group Discovery and the collection settings. To show how, and how fast, it works, I will show it with my Microsoft Office 2013 Security Group and that means the following configuration:
- First thing is to enable delta discovery. To configure the delta discovery navigate to Administration > Overview > Hierarchy Configuration > Discovery Methods. Now double-click Active Directory Group Discovery to open the Active Directory Grou Discovery Properties and go to the Polling Shedule –tab. Select Enable delta discovery and leave the Delta discovery interval (minutes) default.
- Note: Delta discovery does NOT work for deleted objects from the Active Directory.
- Second thing is to configure the collection query and to enable incremental updates on the collection. To configure the incremental updates navigate to the collection Properties and then the Membership Rules –tab. Now select Enable Use incremental updates for this collection and add a Query Rule for the members of the Microsoft Office 2013 Security Group. For that add the following query:
select SMS_R_USER.ResourceID,SMS_R_USER.ResourceType,SMS_R_USER.Name,SMS_R_USER.UniqueUserName,SMS_R_USER.WindowsNTDomain from SMS_R_User where SMS_R_User.UserGroupName = "PETERTEST\\Microsoft Office 2013"
- Note: To change the interval for incremental updates take a look at this post.
Now making a change to the group membership of the Microsoft Office 2013 Security Group will trigger the following reaction. The first thing that happens, within 5 minutes, is that the Active Directory Group Discovery will start to run. This can be followed in the adsgdis.log and looks like this:
One of the things that this log shows, is that a Data Discovery Record (DDR) was written for group ‘PETERTEST\Microsoft Office 2013’. This DDR looks like this:
| FV° <User Group> BEGIN_PROPERTY <8><Unique Usergroup Name><19><32><PETERTEST\Microsoft Office 2013> END_PROPERTY BEGIN_PROPERTY <0><Usergroup Name><19><32><Microsoft Office 2013> END_PROPERTY BEGIN_PROPERTY <17><Active Directory Organizational Unit><19><64> BEGIN_ARRAY_VALUES <PETERTEST.LOCAL/PETERTEST><PETERTEST.LOCAL/PETERTEST/GROUPS><PETERTEST.LOCAL/PETERTEST/GROUPS/APPLICATION> END_ARRAY_VALUES END_PROPERTY BEGIN_PROPERTY <17><Active Directory Container Name><19><64> BEGIN_ARRAY_VALUES END_ARRAY_VALUES END_PROPERTY BEGIN_PROPERTY <0><Windows NT Domain><19><32><PETERTEST> END_PROPERTY BEGIN_PROPERTY <0><AD Domain Name><19><32><PETERTEST.LOCAL> END_PROPERTY BEGIN_PROPERTY <0><SID><19><64><S-1-5-21-3410556430-1908461509-240868779-1127> END_PROPERTY BEGIN_PROPERTY <0><Object GUID><3><16><0x03E526344A6AEC4889CDCC6DC07A26DE> END_PROPERTY BEGIN_PROPERTY <0><Group Type><8><4><-2147483646> END_PROPERTY AGENTINFO<SMS_AD_SECURITY_GROUP_DISCOVERY_AGENT><PTP><02/23/2013 20:35:01> FEOF FV
After this DDR is processed into the database the next (incremental) collection evaluation will pick up the new member of the Microsoft Office 2013 Security Group as a new member of the collection (PTP00000B). This can be followed in the colleval.log and looks like this:
As my log files show, this whole process took less then a minute. So when a user is added right before the delta discovery starts it can be within a minute that the user is part of the collection. In the most extreme situation when a user is added right after the delta discovery had run and then, when the delta discovery finally runs again, it runs so long that the incremental collection update didn’t pick up the change yet, it takes up two full cycles of, in this sample, 5 minutes. So, also the long answer is between 1 till 10 minutes.
6 thoughts on “Quickly catch Active Directory Group Membership changes in ConfigMgr 2012”
The recommended max for the number of collections with incremental updates turned on is 200. How do recommend doing this when you have significantly more than 200 collections?
It’s a recommendation that also depends on the sizing and performance of the environment. The most important thing is that you’ve got to carefully plan your collections. You have to keep in mind that not every collection needs incremental updates and that, for example, changes with a full collection update will trigger an update on related collections.
The impact of using a large number of incremental collections is the delay (in minutes) before that collection is updated. This is more keenly seen with OSD collections. For example you want to build a PC, so:
you pop it in the collection
x minutes later it appears in the collection (x minutes is the time taken for each collection to be evaluated , time, the number of collections) so lets say 20 minutes for 400 collections set to incremental
Then you have to wait until the PXE Cache timeout has expired ( SCCM 2007 default was 60 minutes http://britv8.com/sccm-2007-cannot-image-devices-newly-added-using-pxe-boot/ , SCCM 2012 may well be the same https://blogs.technet.microsoft.com/configmgrdogs/2012/08/28/configmgr-2012-wheres-my-pxe-cacheexpire-gone/)
So when you want to build a PC It would have to wait between 21 and 80 minutes before the PXE server will know about it
I would only use incremental updates for OSD collections (as MS have recommended to me) and reset the PXE cache timeout to 2 minutes (see links above)
for Non OSD collections I would use powershell https://technet.microsoft.com/en-us/library/jj850152(v=sc.20).aspx to manually update the collection when a device is added
That’s correct, it’s all about performance and sizing. Especially in larger environments it can be challenging to find the correct balance in collection evaluations. Also, beware with manually triggering collection evaluations, as it can trigger a chain of evaluations.
Like I mentioned earlier, it’s all about planning.
Thanks – this worked for me 1st time, whereas a Direct Rule was really hit-and-miss.