Answered by:
OU Query failure

Question
-
I have been trying to create a collection based upon OU membership
The OU I want to use is not seen even when I run : select SMS_R_System.SystemOUName from SMS_R_System
This shows all the other OUs presently used but not all the OUs in the domain.
What do I have to do to make SCCM 2012 query AD to get the OU.
Note even when I write the path manualy it is not seen, I have tried renaming removing spaces etc but there is no change in the listing of OUs seen. It seem that a prepopulated db is being used and the AD is not beeing interigated for new data.
Friday, March 13, 2015 3:44 PM
Answers
-
Since no one has answer this post, I recommend opening a support case with Microsoft Customer Support Services (CSS) as they can work with you to solve this problem.
Garth Jones | My blogs: Enhansoft and Old Blog site | Twitter: @GarthMJ
- Proposed as answer by Garth JonesMVP Saturday, August 29, 2015 4:45 PM
- Marked as answer by Garth JonesMVP Tuesday, March 1, 2016 5:26 PM
Saturday, August 29, 2015 4:45 PM
All replies
-
You need to check the AD System Discovery settings under Administration > Hierarchy Configuration > Discovery Methods to search recursively down your domain tree from a level where all the OU's you want to locate are below it. e.g. if you have a Workstations OU and under this you have three OU's called Finance, HR and Marketing then set the Active Directory container to search as LDAP://OU=Workstations,DC=yourdomain,DC=local and then make it recursively search child containers. This should discover the Finance, HR and Marketing OU's
If you have a OU called Servers at the same level as the Workstations OU with the above settings anything under yourdomain.local/Servers will not be discovered but anything under yourdomain.local/Workstations will.
Hope this helps.
- Edited by Chris (d4rkcell) Friday, March 13, 2015 5:58 PM
Friday, March 13, 2015 5:54 PM -
TY for you reply, but it does not solve the problem as OUs above and below are discovered i.e.
Domain\OU1 discovered
Domain\OU1\OU1a discovered
Domain\OU2 discovered
Domain\OU3 not discovered
Domain\OU4 discovered
Friday, March 13, 2015 6:56 PM -
Exactly what computer are in OU3 and Do any of them have the CM12 client installed?
If yes when exactly did they last run both their Hardware inventory and heartbeat discovery?
Garth Jones | My blogs: Enhansoft and Old Blog site | Twitter: @GarthMJ
Friday, March 13, 2015 7:02 PM -
Are you talking about a user/group OU or a computer/device OU? I assume it is a system OU since you mention the sms_r_system view. Make sure your AD discovery methods are created correctly for the objects you want to discover. You will need to configure system, group or user discovery depending on which type of container you are trying to create a collection for.
Also, you may need to check the "Discover objects within AD groups" as well as make sure "recursive" is checked like DarkCell mentioned. If you just configured the discovery method for a new OU, make sure you right click and "run full discovery now" to pull in the new OU outside of your scheduled refresh cycle.
- Edited by mdkelley Friday, March 13, 2015 7:07 PM
Friday, March 13, 2015 7:03 PM -
Hi
The discovery was for computers, but do not let this distract you as the discovery I used to try and resolve the issue:
SMS_R_System.SystemOUName from SMS_R_System
shows the paths to the discovered OUs without showing any content. It provided some 30+ paths that were all viable and under the root of the domain. The one I am interested in is under the same path structure.
The query though did not show all the paths i.e. no user OUs were visible but that does not matter because when you think about it as it proves that AD is not being interrogated.
All the paths shown were for computer OUs including DCs. It seems that the guy who built it had a discovery at some point and refined that.
I created a new query to resolve the problem I encountered. I changed the names of discovered OUs to see if it picked them up, it did not. I presume therefore I am being presented with fixed data, hence my thoughts that an LDAP data base was being queried not AD, and the base needed to be up dated. I am probably totally wrong about this but logically its seems to be the right deduction
Friday, March 13, 2015 7:19 PM -
The query you mentioned (sms_r_system) will show you which OU a particular client computer is a member of, so you will only see data for machines that were discovered. That is basically the view for system discovery information. Sorry I didn't catch that earlier. That view will not show you all the OU's you discover.
run this powershell query to get a list of the OUs in your AD environment.
Get-ADOrganizationalUnit -Filter * | select Name, Distinguishedname
You may need the AD management pack for this commandlet. more info here:
https://technet.microsoft.com/en-us/library/ee617195.aspx
That will give you an idea of the OUs you should see showing up if you compare it to your discovery settings within SCCM. Use the Get-ADComputer <computername> commandlet to check to see if one of the computers you are looking for is actually in the ADsPath you are expecting it to be in.
- Edited by mdkelley Friday, March 13, 2015 7:51 PM
Friday, March 13, 2015 7:34 PM -
The query though did not show all the paths i.e. no user OUs were visible but that does not matter because when you think about it as it proves that AD is not being interrogated.
You would only see Domain\OU3 (according to your example above) if there is also a client in there.Torsten Meringer | http://www.mssccmfaq.de
Saturday, March 14, 2015 4:08 PM -
Hi Torsten, I will move a computer with a client installed into the OU to verify this discovery, but I feel that the comment is off the mark as with a new build, where no computers have a client installed nothing could be discovered, secondly I can see the Domain Controllers OU and none of them have a client installed, but anything is worth a try I will get on with it tomorrow.Sunday, March 15, 2015 4:31 PM
-
Yes, I know this is an old post, but I’m trying to clean them up. Did you solve this problem, if so what was the solution?
Garth Jones | My blogs: Enhansoft and Old Blog site | Twitter: @GarthMJ
Saturday, August 1, 2015 3:45 PM -
Since no one has answer this post, I recommend opening a support case with Microsoft Customer Support Services (CSS) as they can work with you to solve this problem.
Garth Jones | My blogs: Enhansoft and Old Blog site | Twitter: @GarthMJ
- Proposed as answer by Garth JonesMVP Saturday, August 29, 2015 4:45 PM
- Marked as answer by Garth JonesMVP Tuesday, March 1, 2016 5:26 PM
Saturday, August 29, 2015 4:45 PM