Discovery Methods? (Full Version)

All Forums >> [Management Products] >> System Center Products >> System Center Configuration Manager



Message

rjenk74 -> Discovery Methods? (10/6/2008 6:50:16 AM)

Hello,

Just implementing a new setup and just trying to get my head around the AD discovery options and have a couple of questions!

Without sounding too stupid, do I have to have the system discover switched on to actually return systems within an AD group?

Before you laugh let me tell you my thought process! We a planning to target applications at both users and systems, controlled by AD groups which are queried via an appropriate collection. All new systems are built via OSD with the Client installed (works well), so I thought that as the systems will exist in SCCM once built (which they do), I wouldn't need to 'discover' them within AD. However this doesn't seem to be the case

I have turned on User Discovery which populates the collections ok, so I presume I will have to turn on system discovery also, but would rather not as there are 4000+ 'old system that currently exist (it will be a side by side upgrade) that I don't really want to appear in SCCM.

Of course if the new builds are elsewhere in AD (prob are for policy stuff) then i can just target that part of AD But was just curious what the answer is?

Maybe I have answered my own question but any response much appreciated

Oh and what’s the difference between ‘System Group Discovery’ and ‘Security Group Discovery’? I presumed it was as simple as how the AD group was setup, I.e., a security group or a distribution group, is this correct, or is there more to it?
 
Thanks
BP







skissinger -> RE: Discovery Methods? (10/6/2008 8:05:23 AM)

You don't have to have System Discovery on.  I would recommend Heartbeat Discovery though.  You could have the system receive the ConfigMgr client via a GPO login script for example, and then the system would appear in the console; and would continue to send up Heartbeat discoveries. 

If you wanted to push the client from the console, you could use a routine (like Joeware.net's Oldcmp) to clean up your database of those 4000 old systems.  Or you could move all of those old systems to an OU which you deliberately either set security on so the server can't read it to discover the obsolete computers, or choose to not discover those OUs.  Or you could purchase a 3rd party tool, Enhanced System Discovery (ESD) from SystemCenterTools.com which will not pull back obsolete computer accounts.

About System Group Discovery and About Security Group Discovery

I see you are considering advertising to Users or Usergroups (which contain users).  I spent a couple years at the old job moving them *away* from that, and back to systems.  It's cleaner and easier to manage if you advertise to computers, or usergroups which contain computer objects.  That's not to say it can't be done.  It can.  And because it was so difficult to do, it was likely one of the reasons I had to learn SMS/ConfigMgr so well--just to survive.



rjenk74 -> RE: Discovery Methods? (10/6/2008 9:35:31 AM)

thanks for the reply

heartbeat is indeed on, runs once a week, and the new systems do appear within the console no problem, as the client is part of the OSD build. The problem is, if i set a collection to query an AD group, if the group contains users, they populate the collection ok, but if they contain the newly built machines, they don't? All i have currently switched on, is heartbeat, user discovery and security group discovery.

I read the help files about the different discovery methods, but it still confused me. I thought you had to have the group discovery switched on (either system or security) so you could query the AD groups properly, is this not the case?

As for targetting users, yes this concerns me, as we have only targeted systems before, which works fine but the 'customer' wants users to be able to wander to any pc and to install software as they see fit, thus they want non-mandatory apps at users. Technically is appears to work but i can't help but have a horrible feeling that in practice it could be a pain. I was about to create a new topic for this very thing so feel free to answer there with your concerns !!

thanks
Rich







skissinger -> RE: Discovery Methods? (10/6/2008 10:06:22 AM)

Yes, in practise it is a huge headache for you, and for the Asset Management team (if that isn't also you) that has to later try to figure out if you are out of license compliance; and the company needs to spend $$ to true up their licenses.  Often if you bring $$ into the equation, you can get Management to see that a little bit of back-end work by you or the helpdesk will save them money in the long run.  (In general, the saving of time for you or the Asset Mgmt team is often discounted!)

I know I've already mentioned a for-pay 3rd party tool (ESD), but there are also additional 3rd party tools (again for $$) that will make your life, and the Asset Mgmt teams life; as well as the end users ability to install apps wherever they roam quick and easy.  They are often referred to as "Shopping" applications.  The two that I hear the most about are from 1e.com, and sccmexpert.com.  I recommend checking them both out, and see if a shopping interface will save time, money, and help with license compliance at your company w/ConfigMgr.  I know either company would be happy to talk with you.  I know both often have webinars showcasing their Shopping tools.  I know lots of companies who absolutely love the Shopping tool interface.

Back to your collection/discovery issue... are you trying to have computer names in that collection, based upon if the user who has logged in is in a usergroup?  If so, that is possible, but definitely not easy.  I've done it, using a quasi-complicated method of determining "highest ranked user" of a computer.  In your situation, where users wander from box to box, that wouldn't work because the new user wouldn't be the highest ranked user within the first 5 minutes of logging in.

What is the query you are using to populate that collection?



rjenk74 -> RE: Discovery Methods? (10/6/2008 12:52:04 PM)

hey mate, again thanks for the reply, and yeah i think the assest management will be a huge problem and whilst not me as such, it will be me that needs to supply the info and possible solution!! I heard about the shopping tool, though never seen in action but sounds like could be a good alternitive, so will deffo look into!

If we leave the licence issue aside, and just concentrate on the technical side of things, can the user targetting work well or are there other techinal issues that will cause me a headache?

As for the collections, its quite straight forward really so sorry for the confusion. Basically every application we add to SCCM will have its own advert and collection. Then each collection 'points' to the appropriate AD group.

Then when we add either a user or system to the AD group which in turn should then populate the collection and thus run the advert. So for example, for the Visio app we add the user into the AD group and this populates the collection fine, and thus the users see the advert in the run advertised program list and can install whenever (non mandatory advert). However when we add systems to an AD group, such as Acrobat, they don't appear in the collection. However, the systems in question DO exist in the SCCM console as they were built via OSD.

So my question was is this because i don't have the system discovery swiched on? I thought that having the security group discovery swiched on would be enough IF the system already existed in the SCCM console but it appears not?

cheers









skissinger -> RE: Discovery Methods? (10/6/2008 2:54:34 PM)

For me, look at this:  In the SMS Console, pick a computer you know has been added to an AD group days/weeks ago.  If you right-click it, and look at it's properties, and scroll down, do you see any System Group Names for that computer?  If not, then yes, you may need to enable a system group discovery agent.

In the SMS Console, find a collection, like the Acrobat one.  If you go to properties, Membership rules tab, double-click the rule, and click on Show Query Design; copy & paste that result here.  That will tell us what you are using for a collection query.  That should help us understand what you have in relationship to what you want.



rjenk74 -> RE: Discovery Methods? (10/9/2008 5:57:47 AM)

Hey Sherry

sorry for late reply, been away! Anyway as requested the queury for the collection is as follows:

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 = "TLUSER\\SWDeployU-Adobe_Photoshop_v7.01"

All the collections are the same but point to an appropriate AD group. If the group contains users, then the collection populates ok. If the group contains systems it doesn't. I know at least 2 systems in the AD group that have been part of SCCM for over two weeks (via OSD build), however following your advise, in the properties of each there is no mention of any groups. This leads me to beleive that i will need to switch on the system discovery in order for the collection to be populated!

any thoughts much appreciated

thanks



skissinger -> RE: Discovery Methods? (10/9/2008 8:47:52 AM)

Once you get system group names listed on a computer object, you next step will be to add an additional collection membership query to that collection.  Right now, the query is looking only for user resourceids; and you'll want to add the query to also look for computer resourceIDs in that group.  For example:

select sms_r_system.resourceid from sms_r_system where sms_r_system.systemgroupName = "TLUSER\\SWDeployU-Adobe_Photoshop_v7.01"

I've already ranted about my stance on advertising to users, so I won't repeat it here.  I could see targetting something like Adobe Reader or other applications that your company has a site license for, to the "All XP Workstations" collection for example.  But advertising something like, say... Photoshop... which costs $$$ per license, what are they doing for license compliance?  I could quickly see the scenario where you buy 1 license for 1 person in a department, and then they log into everyone's box and install that expensive software.  If I were you, find out who in the company is liable for license compliance (who is going to go to jail when this blatent stealing of software is audited).  It might even be you because you're the one who designed this method of deploying software.  Once you bring up fines, jail time, etc; perhaps a small bit of front-end checks and balances may no longer be roadblock!



rjenk74 -> RE: Discovery Methods? (10/9/2008 10:19:50 AM)

sorry, i gave you one for AD groups containing users

an example of one for systems is below:

select SMS_R_System.ResourceID,SMS_R_System.ResourceType,SMS_R_System.Name,SMS_R_System.SMSUniqueIdentifier,SMS_R_System.ResourceDomainORWorkgroup,SMS_R_System.Client from SMS_R_System where SystemGroupName = "blah blah blah"

like i say, it doesn't' appear to populate the collections so am thinking i must have to have system discovery enabled for this to happen?

As for targetting users, time and time again we have raised our concerns, specifically about licenses as well as support, but the project wishes to go ahead and i have to do what i am told however i have plenty of caviats in place, i.e. don't blame me guvner :-)

Now I do have another question with regards to the discovery methods, how 'low' can i set the time without causing network or processer issue? I know the default is a day though i see in other posts you had them set as every 6 hours? Reason i ask is i would like to know how low i could get an SLA from when a user/system is added to an AD group to when it becomes available to them.

Our collections are set to update every 2 hours but i have been advised by 'others' not to have the AD discovery too low, they recommended leaving at a day therefore it could be 1 day and 3 hours (an extra hour for machine/user policy) before and app becomes available. However i wondered if it really causes that much traffic/data to have discovery lower? We currently have 7000+ user objects and about 5000+ systems. The network links are big, and the central server is fast. So if i set the AD discover to every couple of hours for example, would the number of ddr's flying around every couple of hours actually generate that much taffic? basically are the 'others' being too cautous?

As if the AD was every 2 hours, then it would be a max of 5 hours from AD to machine!

thanks do much for the info so far and as usual any thoughts much appreciated
thanks
BP




skissinger -> RE: Discovery Methods? (10/9/2008 11:42:36 AM)

The answer everyone hates:  "it depends".  Just test and see what happens.  For example; maybe drop it to hourly, and monitor the discovery logs, and monitor the ddm.box inbox for backlogs.  Because a backlog may creep up slowly, or if there is a bad DDR it might cause huge backlogs quickly, I recommend adding to your daily task list of "is my ConfigMgr Site healthy today" to just look at that inbox size (both size in MB and size as in # of .ddr files).  That 30 seconds a day might save you a huge headache one day.

If you see backlogs occur; change it from hourly to maybe every 70 minutes, then 80, etc (or down from 60 to 45 if you want to try tighter).  Once you hit a comfort zone; stick with it.  Since you'll be watching the inbox daily, when your infrastructure grows you'll be able to make adjustments as needed.



rjenk74 -> RE: Discovery Methods? (10/10/2008 3:19:00 AM)

thanks fo the reply (again!) and yeah 'depends' is pretty much what i thought :-) I think thats why you get such a huge difference of opinion.

The funny thing is, the user discovery did get set to 1 hour for a few days, and whilst the ddm log file was overwritten in a really short time (only set to 2.5 mb) there was never any backlog of files to be prossesed. This led me to believe that we could deffo have the discovery set to less than a day, even every 6 hours would be good!

the problem is i can offer no solid reason other than, 'well lets just do it and monitor'  (i do have set of daily health checks, inboxes being one of them. ) which usually isn't good enough a reason for some people :-)

thanks again






Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
0.25