If you re-image machines pretty regularly, as part of that process I would retire the existing asset in Inventory. You are taking the machine and recycling it so that original machine configuration is no more. Retiring the asset in Inventory still keeps a read-only copy of the asset for historical purposes.
I forgot to mention that I created custom fields under the manage tab for order data, PO, Mfg date, status, and warranty. I assume there is no way to move that info over to a new asset? Also, following your advice, we should manually retire every asset when a renamed version of it is discovered? Will retiring it free up the license for the auditing software?
No way to automatically transfer the data in custom fields from the retired asset to the new one. I wouldn't wait until a new item is discovered personally. I'd actually make it a part of the recycle process that when you take an existing machine out of service in order to re-image it that you also go into Inventory and retire it. And yes, retiring the asset frees up the Audit license and it also frees the machine's software licenses from existing software licenses if you using the Software Licenses feature.
1 of 1 people found this helpful
Excellent -- thank you for the assistance.
During the Discovery Reconciliation process, you're currently accepting Discovery's suggestions. Discovery sees this as a new machine, and suggests that it be added as a new machine. Instead, you can over-ride that, and link the newly Discovered machine to the previously existing entry.
This Community post talks a bit about how Discovery finds information from machines.
This post talks more about the Audit itself.
So, Discovery is light and fast, and very limited on what it finds. It puts everything into a "holding container", and you have to manually reconcile it. Audit on the other hand is slow, but very detailed. The Audit puts its results into an XML file, and delivers that to the Track-It! server. The server then runs a Merge, and the Merge compares the data in the XML to the records in the Inventory module to determine if these audit results represent a new machine, or an existing one. It then updates the Inventory module directly, with no action on your part.
This knowledgebase article explains what the Merge looks at in order to determine if this XML is a match to an existing asset record, or needs to create a new one. To summarize those:
1) TIA Environment Variable
2) TrackitAudit.id file's ID value
3) MAC Address + Computer Name
4) Computer Name + Service Tag
5) MAC Address + Service Tag
6) MAC Address + IP Address
It's highly unlikely that you use TIA variables. Those are pretty old, and only a few customers still even know about them. The TrackitAudit.id file is no longer "static", but changes with each audit to eliminate issues that occurred when an audited machine was used as a Ghost or similar image on several machines.
That leaves the Mac Address + Computer Name, and so on down the list. If you audit a machine, then format it and install a new OS on it; as long as it still has the same NIC (and therefore the same MAC address) and you give it the same name as it had before the format; then the audit will assume this is the same machine that it's been updating all along.
If for some reason you give it a different name (maybe a typo?), the MAC Address + Service Tag (item 5 in the list above) should still match up, and the Merge should still update the previously existing record instead of creating a new one.
Based on all of this, you may find it less manual-labor-intensive to turn off Discovery, and use a login script or something like that to initiate your audits. This Community post talks about different ways to initiate audits.
Finally, if you use an initiator other than Track-It!, you don't need that little piece of software that you mentioned. That's our Workstation Manager, which is discussed in detail in this Community post.
You mentioned above that "It's highly unlikely that you use TIA variables. Those are pretty old, and only a few customers still even know about them. The TrackitAudit.id file is no longer "static", but changes with each audit to eliminate issues that occurred when an audited machine was used as a Ghost or similar image on several machines."
In the interest of future Track-It users, our Helpdesk team would like to respectfully suggest that BMC update KB article TIA00820 to reflect that it is actually inadvisable to use custom TIA variables on end-user workstations, because it then links the asset number to the hard drive of a computer, and not its motherboard. As highly unlikely as it may seem, our IT department was defining custom TIA variables long before I arrived, and I just assumed that it was good practice to continue doing so until I read your post.
Since the TIA variable takes precedence over the Computer Name, MAC address, Service Tag, and IP address, this can cause issues if a Technician swaps out a hard drive and doesn't update the TIA variable. This step is easy to forget if one needs to replace a laptop quickly and a previously TIA-defined hard drive gets recycled into another workstation.
When my manager submitted a support ticket asking for help with the audits, he was sent that KB article, which neglects to mention that. We've pushed out a group policy to delete all TIA system environment variables from our machines, and will be retiring our old records and rebuilding new ones with the Track-It server's defined asset numbers.
Anyways, we've all had a lively debate about the audit process and your input seems to have brought everyone to the same page, so on behalf of the Team, thank you for your posts.
Glad all my typing was for a good cause.
We'll revamp the wording on the article. I'm hesitant to say it's "inadvisable".....because there are some very specific use cases where it may be a good option. However, using a TIA variable puts a lot of responsibility on manually over-riding our automated merge linking. Therefore, I'd be more inclined to elaborate on it in the article, so that the folks who do use it understand that it really shouldn't be needed for most cases, and if they do use it, they understand the ramifications.
Anyway, glad you got it all sorted out!
That sounds reasonable. I can see custom TIAs being useful in certain security contexts. In other news, all of our inaccurate asset records corrected themselves with the latest merge.
HI Keith, Hopefully you have not already covered this. Is there a method you know of where the Asset Name field will reject any duplicate entry attempts and log these attempts? Thanks, John B.
There isn't. There are many legitimate reasons where some Track-It! users may want to "re-use" a name.
For example, say the Database server is named DBSVR, and has been audited and is now in Track-It!'s Inventory module. Say, too, that the server suffers a catastrophe. As a result of the catastrophe I build a new database server with the same name, and restore all of my database backups to that new server. If Track-It! simply rejected the creation of the new record, you would never know that the new server wasn't audited and in the system unless you spent a fair amount of time watching the logs.
As it works right now, you would end up with two asset records names DBSVR. One would have a recent audit date, and the other would have an audit date that was old and never updating.