System OU Name data missing
When our AD discovery runs, it does not seem to be pulling back the SMS_R_System.SystemOUName back. I use this data to see which OU the computer has come from. Does anyone know why it is not being pulled back in to SCCM? When I do a query against the computer object, the field is blank...
I run the AD Sys Discovery every day, and from the log, it seems to be running OK. I run the AD Security Group discovery every 5 miuntes (targetted to one OU). Again, this seems to be running OK.
How do I get the System OU information for each object to update the SCCM console so I can use it in queries?
Thanks- Edited byTom Whiteley Sunday, October 25, 2009 7:36 PMclarification
Answers
- It gets it for each system that is assigned to the site and populates the OU for each one.
Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys- Marked As Answer byWallyMSFT, OwnerMonday, October 26, 2009 4:30 AM
All Replies
- OUs are returned by the System Group discovery.
Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys - Does that get the OU for each object then? And if I run that discovery, will it populate each object's OU?
- It gets it for each system that is assigned to the site and populates the OU for each one.
Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys- Marked As Answer byWallyMSFT, OwnerMonday, October 26, 2009 4:30 AM
- BTW every 5 minutes might be a bit much, even if it is just one OU.. Why so often?
http://www.enhansoft.com/ I am sorry, I think I meant security group discovery... We use it for our servicedesks to add computer objects in to an AD group, then have a advertisments for them... So I'll check the system group discovery.
Thanks guys.If you are advertising to a security group then it only need to be discovered once. After that when a PC is added to the group that PC needs to reboot in order to receive the advert. Doing more AD Group discovery will not short this time frame.
http://www.enhansoft.com/- I see, I will lengthen the discovery time in that case, I assumed that it would poll the members of the group to help speed up deployment. Thanks for your advice Gareth.
- Actually, unless I'm thinking of something else (always possible), you cannot advertise to computers that are members of AD security groups, only users. If you use AD System Group Discovery, then you can successfully advertise to computers that are members of the group, however the target system would have to be a member of the collection, which means a new discovery process after adding the system to the collection.
The two discovery methods differ in that aspect, so something to be aware of.
Wally Mead - If you are not changing the Access Accounts on the Pacakge, you do not need to reboot the computer to receive the advertisement or install the software after you add the computer(s) to a security group. Just run a AD System Group Discovery, Update the Collection Membership and kick off a Machine Policy Retrieval to speed up the process. If you are changing the Access Accounts on the package, which changes the NTFS permissions on the DP, (e.g. remove the Users group and add the Security group you just added the computer to) then you would need to reboot the computer in order to receive a new Kerberos Ticket that contains the latest AD information such as group membership SIDs which provides the authentication to all other AD resources.
- True, and not true.
Funny, but everyone is this thread seems to be right, just depends on how you advertise.
If you advertise to the group, than Garth is right and a reboot is needed, and Wally is right, this will only work for groups discovered by Ad system group discovery.
You are right assuming you advertise to a dynamic collection based on ou membership.
"Everyone is an expert at something" Kim Oppalfens Configmgr expert for lack of any other expertise. http://www.scug.be/blogs/sccm
