none
Change in inventory frequency ignored

    질문

  • Greetings,

       We used to set our inventory using a custom schedule for the same time every day. I changed this last week to a simple schedule every 7 days. Most machines are ignoring this and still collecting the inventory the same time every day as per the old custom schedule. After a week they surely should have received the policy change. Some machines seem to have responded and have not inventoried in the last week. Any ideas on why most machines are ignoring the change?

    Thanks

    David Z

    2012년 2월 17일 금요일 오전 3:10

답변

  • I asked that several years ago, "what is it really for"?  Here was the response.  What it does, is it will create for you the rules in the SW Metering node set to "false".  so that you can, when you feel like it, just go into the node and change any specific one that strikes your fancy to be enabled.

    So... that's all it's for?  Makes up my rules for me?  Well, by now you likely have most things.  Basically, now if I get in a new software or version of Widgets 4.0 that I need a new SW metering rule for, I just make it up manually.  Sure, it's a bit of a hassle every 3-4 months when someone asks me why Widgets 4.0 isn't showing up in the SW Metering reports.  But the processing savings and db savings is worth the minor hassle.

    There is one or two third party add-ons that leverage the CCM_recentlyusedapps data, so if you have some 3rd party addon things, especially something that heavily relies on SW Metering type data, that add on might need your returned information in ccm_recentlyusedapps.  If you have any 3rd party tools for CM, just ask the vendor if they rely on that data before you change it to FALSE. Oh, and if you *do* need it set to be true, but your citrix or app servers send up obnoxiously huge mif files, here's the local policy override for that:  http://myitforum.com/cs2/blogs/skissinger/archive/2009/07/03/selectively-disable-ccm-recentlyusedapps-per-client.aspx

    We've had ccm_recentlyusedapps set to FALSE in our sms_def.mof file for well over a year; no impacts to the *existing* SW Metering rules.  Obviously no new 'disabled' rules are created for me.


    Standardize. Simplify. Automate.


    2012년 2월 20일 월요일 오후 11:30
  • I understand 70k clients is a lot.  But... we have over 300k clients.  and Daily Hinv.

    But that's not your issue, correct... I know daily hinv is recommended, and not a big deal even in the largest environments.  Your issue is that you don't want daily, but clients are doing daily regardless.

    So... why are they?  While monitoring policyagent on a client, make a change to hinv from daily to every 2 days, and then trigger a policy refresh on that client.  Does the policy even make it to that client according to policyagent.log? 

    This is unlikely, but you never know... did someone, years ago perhaps, send out a Local Policy Override to the majority of your clients so that they all do a daily local Hinv, regardless of the server policy?

    Do you have multiple MPs behind an NLB?  Is it possible that 1 of the MPs is ailing, and offering stale policies to clients, but the other one isn't?

    anyway, I still think daily hinv is fine, no matter how large your environment.  Well... if you have obnoxiously huge mif files, I'll bet it's because of CCM_RecentlyUsedApps.  We've turned that off in our sms_def.mof file so that our hinv delta mif files are teeny.  Another off-topic tip; really way off topic, but if you get backlogs in inbox processing, check this out: http://myitforum.com/cs2/blogs/jnelson/archive/2009/12/09/143643.aspx


    Standardize. Simplify. Automate.

    • 답변으로 표시됨 David Zemdegs 2012년 2월 20일 월요일 오후 8:23
    2012년 2월 20일 월요일 오후 3:31

모든 응답

  • Oh, I'm sure they have received the policy change.

    But, the schedule is still every 7 days, correct?  So each client will look locally at "when did I last report hinv", ah, exactly 3pm on Wednesday.  So that's when I'll "randomly" report hinv this time.

    Here's my opinion...Hardware Inventory is "valuable" in my opinion.  make it daily.  Software Inventory keep that weekly, it's not as valuable info IMO.

    So, set the hinv schedule to daily; perhaps after hours when a good population of your computers are offline.  The ones still online after you change it to daily (and it is more than 24 hrs since they last sent up hinv) will run a hinv delta that evening.  As computers boot up in the morning and get the new policy, they will run their hinv delta in the morning.  Over time, as computers reboot for different reasons at different times, it will be even more random.

    So if currently 90% of your computers are reporting hinv weekly around 3pm Wednesday, sometime after 6pm on Thursday (if most computers are offline by then) change your policy to daily.  If the culture is that people don't turn off their computers on a weekday, but may on a weekend, instead change the policy on a Friday night.


    Standardize. Simplify. Automate.

    2012년 2월 17일 금요일 오후 12:48
  • Thanks,

      The problem is that even though I have said 7 days, the machines are doing the inventory daily. IOW they are ignoring my policy change.

      I cannot do daily as we have to do everything to minimise network traffic and with about 70000 clients we cannot justify daily. Besides, we dont need the data to be that up to date.

    Cheers

    David

    2012년 2월 19일 일요일 오후 8:47
  • IMO Daily Hardware Inv. will have little to no effect on the network.  Yes you will end up with more data crossing the network but it will happen in smaller chunks and at more random times. Personally I turn off SW Inv and I would enable daily HW Inv and enable the AI classes. By turning off the SW Inv. You will see (IMO) overall less data crossing then network vs having (SW & HW set to weekly)



    http://www.enhansoft.com/

    2012년 2월 19일 일요일 오후 9:16
  • I understand 70k clients is a lot.  But... we have over 300k clients.  and Daily Hinv.

    But that's not your issue, correct... I know daily hinv is recommended, and not a big deal even in the largest environments.  Your issue is that you don't want daily, but clients are doing daily regardless.

    So... why are they?  While monitoring policyagent on a client, make a change to hinv from daily to every 2 days, and then trigger a policy refresh on that client.  Does the policy even make it to that client according to policyagent.log? 

    This is unlikely, but you never know... did someone, years ago perhaps, send out a Local Policy Override to the majority of your clients so that they all do a daily local Hinv, regardless of the server policy?

    Do you have multiple MPs behind an NLB?  Is it possible that 1 of the MPs is ailing, and offering stale policies to clients, but the other one isn't?

    anyway, I still think daily hinv is fine, no matter how large your environment.  Well... if you have obnoxiously huge mif files, I'll bet it's because of CCM_RecentlyUsedApps.  We've turned that off in our sms_def.mof file so that our hinv delta mif files are teeny.  Another off-topic tip; really way off topic, but if you get backlogs in inbox processing, check this out: http://myitforum.com/cs2/blogs/jnelson/archive/2009/12/09/143643.aspx


    Standardize. Simplify. Automate.

    • 답변으로 표시됨 David Zemdegs 2012년 2월 20일 월요일 오후 8:23
    2012년 2월 20일 월요일 오후 3:31
  • Thanks Sherry, You certainly beat me on the client stakes!

    And thanks for the great tips.

    Your tag line is awesome (SSA). I hope you dont mind if I borrow it - precisely the way I like to use IT.

    Cheers

    David Z

    2012년 2월 20일 월요일 오후 8:25
  • Just a question on CCM_RecentlyUsedApps if I may. What relationship does this have to the validity of software metering data?

    Thanks

    David Z

    2012년 2월 20일 월요일 오후 8:39
  • I asked that several years ago, "what is it really for"?  Here was the response.  What it does, is it will create for you the rules in the SW Metering node set to "false".  so that you can, when you feel like it, just go into the node and change any specific one that strikes your fancy to be enabled.

    So... that's all it's for?  Makes up my rules for me?  Well, by now you likely have most things.  Basically, now if I get in a new software or version of Widgets 4.0 that I need a new SW metering rule for, I just make it up manually.  Sure, it's a bit of a hassle every 3-4 months when someone asks me why Widgets 4.0 isn't showing up in the SW Metering reports.  But the processing savings and db savings is worth the minor hassle.

    There is one or two third party add-ons that leverage the CCM_recentlyusedapps data, so if you have some 3rd party addon things, especially something that heavily relies on SW Metering type data, that add on might need your returned information in ccm_recentlyusedapps.  If you have any 3rd party tools for CM, just ask the vendor if they rely on that data before you change it to FALSE. Oh, and if you *do* need it set to be true, but your citrix or app servers send up obnoxiously huge mif files, here's the local policy override for that:  http://myitforum.com/cs2/blogs/skissinger/archive/2009/07/03/selectively-disable-ccm-recentlyusedapps-per-client.aspx

    We've had ccm_recentlyusedapps set to FALSE in our sms_def.mof file for well over a year; no impacts to the *existing* SW Metering rules.  Obviously no new 'disabled' rules are created for me.


    Standardize. Simplify. Automate.


    2012년 2월 20일 월요일 오후 11:30
  • Well I guess its an easy decision for us as we dont use software metering at all.

    So its just a matter of changing all the sms_report(true) to sms_report(false) in that class in sms_def.mof? And it will automatically delete the db data as well?

    Thanks

    David Z

    2012년 2월 21일 화요일 오전 12:26
  • oh, yeah, not even a question then.  On all your primary sites' \inboxes\clifiles.src\hinv, open up sms_def.mof, find this:

    [SMS_Report(TRUE),
    SMS_Group_Name("CCM Recently Used Applications"),
    SMS_Class_ID("MICROSOFT|CCM_RECENTLY_USED_APPS|1.0"),

    and change it to

    [SMS_Report(FALSE),
    SMS_Group_Name("CCM Recently Used Applications"),
    SMS_Class_ID("MICROSOFT|CCM_RECENTLY_USED_APPS|1.0"),

    Save the file.  As long as you didn't misspell the word "false"  :)  you don't even have to watch dataldr.log on the primary sites.  But if it makes you feel better, watch the log.

    What will happen is after clients pick up the changed policy, the next time they won't report anything for that.  "eventually" that data will age out.  It may take a while; it really depends upon how you have your "delete aged" stuff set.  I wouldn't worry about it, though; it'll disappear over time.

    As long as we're talking optimization... you don't have every single Asset Intelligence class enabled do you?  ones like SMS_Shortcut are brutal, too.


    Standardize. Simplify. Automate.

    2012년 2월 21일 화요일 오후 2:53
  • Thanks again for your tips. Asset Intelligence is already off.

    Just as an aside i had a meeting with the guy who is responsible for the 70k desktops that I have to deploy the agent to.

    When I said that basically no-one will notice it has happened and that there are neglible performance impacts (hence my concern on inventory frequency), he rolled his eyes and said that he had heard the same thing from other people about other software that turned out to be false.

    Now he wants performance data. e.g. whats the time difference between normal startup and startup when the agent installs? What performance hit is there on a client doing an inventory cycle? I was wondering if any logfile reports the file size of the inventory data sent from the client as inventoryagent.log doesnt seem to have it.

    2012년 2월 21일 화요일 오후 9:06
  • the size won't be reported, but you can capture samples easily enough.

    in http://www.myitforum.com/myitwiki/sccminv.aspx at the bottom under sources, one of the links to a troubleshooting doc talks about adding a file to a folder on a client (the RickyM/Russ Slaten one), so that the next time inventory runs, the mif file isn't deleted after being submitted.

    So... do that.  Run a sample delta (with ccm_recently on).  Run a sample Full (Client Center will let you trigger a full) with ccm_recently on.  Then turn off ccm_recently, bunch o'policy refreshes on the client, and run a delta and a full again; then show him the .mif file sizes.  You, and he will be satisfied.

    If he still isn't comfortable, ease in the change.  Change it from weekly to every 6 days.  then a week later, from every 6 to 5 days.  Slowly decreasing it, and have him monitor the network so he can detect any trends going in a bad direction.  I'm sure he'll notice nothing.

    I'm not quite sure I know what you mean by "normal startup and startup when the agent installs".  During initial install of course there is a lot more going on, and policies need to be picked up and evaluated, actions taken based on those policies for first time use.  and of course that depends upon hardware too.  multi-threaded/proc?  good drives?  Or something pulled out of a closet?  Or an under-powered Virtual machine?  I've seen anywhere from 2-3 minutes (on killer hardware) to 20 min or longer on junk.  On what I consider a "normal" workstation, I usually see about 7-8 minutes for the box to be awake enough to start doing inventory.  I have a 'special geeky' Fast Collection setup just for patching, and I get new Win7 boxes that install the cm client patching within 12-15 minutes of the client installing.  (those are the Win7 clients that appear out of nowhere... the ones not imaged where or how we expect them to be imaged.  with 300k environment, there are pockets of techs everywhere--so it's a way to find and patch those rogues quickly; when we don't have NAP)

    I think Garth and I mentioned this before..hardware inventory isn't the problem on clients.  SINV is what is a pain in the ... on a client.  If you still have the default in sinv of *.exe on all drives, check this out: http://myitforum.com/cs2/blogs/skissinger/archive/2011/10/04/software-inventory-tips-for-configmgr.aspx


    Standardize. Simplify. Automate.

    2012년 2월 21일 화요일 오후 10:47
  • Thanks heaps. Over and out....
    2012년 2월 22일 수요일 오전 12:17