How to prevent systems being discovered from an OU and its child OUs to avoid pushing agents?

Hi all,

I was wondering if anyone tried this before as I am trying to avoid an OU and chid OUs from being dicovered to avoid client pushes. System Discovery is currently set to the top level but one of the Organization Unit needs to be skipped. I tried following but its not working

Set computer object (DOMAIN\SERVER01$) DENY "list contents" permission on desired OU (OU1)

When I re-run the full system discovery it was still reading systems from OU1 and its child OUs

Retried with DENY "all permissions" on OU1 but its still reading OU1 and its child objects..

Anyone know what I am doing wrong and why system is still reading OU?

Thanks

February 4th, 2014 11:14am

Deny permissions don't work because of inheritance precedence -- I don't remember the actual specific technical details off hand though. It's not that it can't work, but it would take a lot of changes to your AD permissions.

You'll have to reverse your thinking and only include the OUs that contain the systems that you want. That certainly adds complexity though.

Another possibility is to use Security Group discovery. Essentially, you add all of the systems you want to be discovered into a security (or multiple security groups) and then add those (and only those) to security group discovery.

A still further possibility is to use a client startup script to deploy the client agent; instead of relying on AD Discovery to find in-scope systems, you only assign the startup script to in-scope OUs using a group policy which you could control using security group membership and/or inheritance blocking.

Yes, OU exclusions in AD System Discovery would make life easier though.

Free Windows Admin Tool Kit Click here and download it now
February 4th, 2014 12:50pm

Cannot do reverse thinkging will create a mess and will flood the OU names in system discovery applet. Been there and done it 2007 days but want to find a cleaner way.

If permission can be revoked on desired OU then technically it should function... My issue is that Primary Server is still able to read objects even it has explicit DENY all permission.

February 4th, 2014 1:03pm

Instead of pointing to the root, can you just setup the discovery to point to each of the children of the root that you are interested in minus the OUs you aren't?  More work, but pretty easy.
Free Windows Admin Tool Kit Click here and download it now
February 4th, 2014 1:07pm

No, as mentioned, it has to do with explicit permissions being overridden by inherited permissions so your explicit deny is be trumped by an inherited allow (or something like that -- as mentioned, I don't remember the exact details anymore). Without reorganizing all of your permissions (including default AD permissions) you can't get there from here unfortunately.

You'll have to try one of the other suggestions.

February 4th, 2014 1:13pm

As I mentioned in my above response that we had that setup in our SCCM 2007 days but dont want to do again. Trying to find why SERVER01$ still able to read OU1 while it has set DENY to "all permissions". Is the System Discovery using other account then Primary Server's System Name (SERVER01$)?

Free Windows Admin Tool Kit Click here and download it now
February 4th, 2014 1:14pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics