RHopkins

Nick

Are you talking about the Recreate Full Inventory?

If so then I would tell you that there is no "NEED" to run this, generically speaking. It's purpose is to flush existing information from the database and replace it with new. If you feel that the incremental inventory updates (Hardware, Software & User, by default) are accurate then I would tell you not to worry about running it.

__________________
Scire potentia est (knowledge is power)

RHopkins

Yeah, thats what I'm talking about. Thanks for the feedback. Would you say maybe once a year or once every six months just to clean things out would be a better practice?

Nick

I would say that it truly depends on each environment.

I've seen some organizations that don't care about what their hardware inventory is except once a year. Based on that I could set policies for them to start running hardware inventory or a refresh a couple of weeks before they were interested to make sure the data was current.

I would suggest that you review your internal policy and go with what seems to make the most sense. If you don't have a IT policy for this yet I would say run with it and implement one.

__________________
Scire potentia est (knowledge is power)

JenH

At Manage Fusion, a couple of the Product Engineers actually recommended doing the Full Inventory more often.

Is there Pros and Cons to doing the Full Inventory more often vs. less often? Just trying to understand if we lose anything by not keeping with the default Monthly Inventory schedule. We do a lot of monthly reports, so don't know if this will affect those results or not. If not, great, if so, then we'll need to evaluate the schedule we should keep.

Anyone else want offer their experience/opinions/practices as far as the Full Inventory scan is concerned?

If we do expand the schedule, should we keep the Basic Inventory to weekly or should that be done less often as well? We've pretty much done most of the Inventory scans "out of the box" since we started using Altiris. We do have auditpls.ini set to best practices, but that's pretty much all we've done. I'm sure there's more exclusions, inclusions, etc. that we could implement to reduce the impact of the Full Inventory scan when it is scheduled to run.

Thanks again for the feedback.

Nick

I can see why they would tell you to run it more often. It is a good way to make sure the data is very current. I don't want to give the impression I'm an advocate of not running it, just saying I can and have seen where there isn't a driving need in several organizations I've been in to have it aggressive.

Adjusting the auditpls.ini or creating a custom one to gather specific inventory information is definitely a way I would go if I knew there was a subset of data I was particularly interested in keeping up with.

__________________
Scire potentia est (knowledge is power)

EMercado

Just FYI, I recently implemented a recreate full inventory after not doing so for over 2 years. The reason is because I was noticing the following scenario:

• PC A has some hardware data classes missing in Resource Manager.
• I force another hardware inventory run. No change - NSIs not being sent as the client sees no change in hardware.
• I clear the .bak files from the client, rerun hardware inventory, NSIs send, NS gets updated.

I can only conclude that the NSI is malformed and the NS ignores it, or the client creates the .bak file but the NS for some reason never gets or processes the NSI. Recreating the full inventory once a month allows me to clean the folder and get fresh data, forcing the clients to send the information whether they think the NS got it or not. The NS can then use hashes to determine whether or not it needs to update the table, so I'm not worried about too much about NS processing. It works really well for in this case.

andykn

I find it helpful to think of the two main inventories as Hardware and Software. If the Hardware one has any impact on users, you have a problem that needs to be fixed.

Because the Hardware one also does OS, it includes Add/Remove programs, so much of the Software information you need day-to-day you will have.

The problem with not doing a "Clean before run" every so often is that a delta scan may be sitting in a Bad directory somewhere in the NSCAP share; so, without the clean, you'll never see this data. A problem with your NS, causing one whole set of scans to be dumped, could cause an entire software rollout to go uninventoried.

milla

As others have stated the clean before you run is imperial to making sure that data is current and fresh in the ns and not stale data, or data that cannot be processed for whatever reason

While I have scaled back the hardware inventory to once a week, I have created a inventory scan for just Add / Remove programs as this is the most likely component to change in the OS. This runs daily.

And on the software scan side, just run the slow mode switch on the inventory to lower the impact on the user's pc's so they don't notice it running. While it may take longer to complete, you will get a more complete inventory.

andykn

The slow mode is a good idea.

A "clean before run" or "recreate" does not involve significantly more processing power on the client - it still does a full scan, its just whether it posts back the full scan results or deltas them first.

The Hardware (and OS) scan involves so little processing on the client, I wouldn't bother setting up a separate daily scan. It will only post back deltas anyway.

QuietLeni

Dear All,

I am having a problem with the inventory of servers and the problem is that the details that I get back from a "Clean Before Run" Full Inventory are giving an incremented _id in all classes (i.e. NIC1 and NIC2 have IDs in the database of 2205 and 2206, but when the CBR is run, they then have IDs of 2207 and 2208).

This is not usually a problem, as most people don't export their inventory data to an outside system, but we do. The net effect is that, when we export the data to the third party system, we get machines with multiples of NICs, Monitors, Hard disks and... (In my example above, we get MachineX with 4 NICs, not two! )

What we need is a static ID for each item in the database, so that when we export our details, we do not get this ID-Creep.

Ideas in how to achieve this?

Regards,

QuietLeni

__________________
What is the airspeed velocity of an unladen squirrel?
What do you mean; is that an African or European Squirrel?
What, don't know that? Aahhhhhhhhhhhhhhhhhhh!