1 2 Previous Next 15 Replies Latest reply on Jul 2, 2012 3:48 PM by Chris McLane

    Trackit Auditing: Some general questions

      I'm still trying to understand the auditing process, and get regular current and reliable results. I'm currently only getting about a 40% success rate. So I have a a few questions I'd really appreciate help with.


      We're in a windows environment win2008 server with Active Directory and XP and Win7 PC's. All of our PC's are connected to our domain and we are using the domain administrator credentials to audit.


      1. What protocol/service/method is trackit using to connecting to the PC when it attempts to audit them. Remote desktop? Does a specific service need to be enabled?
      2. Does remote access need to be turned on. Firewall turned off?
      3. If a PC is being used or is locked by a user will this have any effect on the auditing process?
      4. What would cause a machine that has been successfully audited in the past to fail auditing when scheduled or manually requested?


      Of the PC's that have been been audited, trackit seems to identify the 'owner'. However we have machines that several people use, or have been redistributed and trackit doesn't show the current user. Some machines that are used daily by a single user show that the 'administrator' is the owner.


      1. When a PC is audited for the first time, if many people have used that machine in the past. Which user does trackit identify as the user/owner?
      2. If the owner changes, and the PC is audited, does trackit update the "current owner". What logic does it apply?
      3. If the user clicks the audit now button in the self service, will that update the details and assign the PC to them?
      4. What other affects will the self auditing function have?


      Any clarification would be greatly appreciated.





        • 1. Re: Trackit Auditing: Some general questions
          Chris McLane

          Hi Peter,


          I'll try to answer some of this:


          1. When a PC is remotely audited, it looks to see that the Audit Agent is installed. The service associated with the Agent is called Track-It! Workstation Manager. If the Audit Agent is not currently installed on the machine, it connects to the Administrative share and installs it. Once installed, the audit runs locally and the data is sent back to the Track-It! server to be merged into Inventory.


          As far as what exactly is required, you must be able to PING the remote machine from the Track-It! server and have it return the same IP Address that the Agent is listening on on the remote workstation. Sometimes DNS will be outdated and the PING will return a different IP address than the one the Agent is installed on. To have the Audit Agent installed remotely if it doesn't already exist, File and print sharing must be enabled and must be allowed through Windows Firewall.


          2. Remote access for Windows doesn't need to be turned on, and Firewall does not need to be turned off. When the Audit Agent is installed, normally an exception for the Track-It! Workstation Manager service is added. You just need to make sure File and Print sharing is enabled as an exception through the Firewall.


          3. If a PC is being used, or is locked the audit will still occur. The call is made to the machine to check to see that the Audit Agent is installed (Track-It! Workstation Manager service is running), installs if if needed, and then runs the Audit process. The machine doesn't even have to be logged on.


          4. The only reasons I can think for why a machine will remotely audit one day but not another is the machine is off/not connected to the network, or DNS is outdated. Or if for some reason the Workstation Manager service is disabled or not installed any longer and fails to install because other pre-reqs are not running (File and print sharing).


          In terms of "owners" of the PCs:


          1. When audited for the first time through scheduled audits or "Audit Now", the last logged on user is supposed to be captured as the "owner" of the PC.

          2. If the owner changes and the PC is audited again, the current owner will be updated IF the following line exists in the Auditcfg.ini file in the ..\Track-It! Server folder on the Track-It! server:




          By default, this is set to a '0', which means the owner will not change if a different user uses the PC so if you want the user to change automatically when someone else uses the PC, you will definitely want to set the value to a '1' in the Auditcfg.ini file.


          3. When the user clicks the Audit Now button in Self Service (10.0 Web and later), it simply tells the Track-It! server to do an "Audit Now" just like a technician would do from the Inventory module. This means it goes through the same process of calling the machine, installing the Audit Agent if needed, running thte audit process and then merging the results back to Track-It! If this is the first audit of the machine it will be associated with the user who is logged in at the time. If the machine had already been audited in the past, the ownership would only change if the line referenced above exists in the auditcfg.ini file.


          4. Hopefully I've answered how the self auditing function works above.

          1 of 1 people found this helpful
          • 2. Trackit Auditing: Some general questions



            Thanks Chris for such a brilliant explanation. Thats given me several great leads to follow up.





            • 3. Re: Trackit Auditing: Some general questions

              Progress... of sorts...


              I've modified the Auditcfg.ini file and enabled OverwriteExistingUserAssociation=1. It will be interesting to see what impact that has.


              I've spent several hours today working through a few examples of machines that are being a bit stubborn to audit.


              Some problems I have identifed so far include: PC names changing, the machine was picked up in a network scan and added to inventory. The PC name was changed. Trackit appeared to be trying to use the existing name to connect. After I had edited the record and updated the name, Trackit succesfully audited the PC. However instead of update/merge with the existing record, it inserted a new record in inventory. (Is this the expected behaviour?)


              We've had a few odd DNS responses. Pinging a specific named machine and then getting a resposnes back from an unrelated machine. (Obvioulsy not trackit's fault)


              A couple of PC's refused to be picked up by the sceduled scan, but when scanned manually it was successful. (what was different?)


              When scanning PC's on demand few report they've been successfully scanned ( several times) but the machine details are not showing anything different. Computer make, model, Win version etc aren't being detected. I have clicked refresh, closed and reopened the technician client and nothing changes.


              If I have manually edited any fields, will trackit refuse to update with the audited detail for the whole PC or just the fields I have modiifed?


              Would fixed IP addresses influence trackit at all?  We have a few users on fixed IP's who have been upgraded and thier new PC's given the same IP. If trackit knows another PC has had that specifc IP, would that have any effect?


              Thanks in advance for your assistance.





              • 4. Re: Trackit Auditing: Some general questions
                Chris McLane

                The OverwriteExistingUserAssociation=1 value will definitely update the user names after every audit if the last logged on user changes.


                When you run a remote Audit, it does indeed use the existing record's PC name to find the matching asset on the network by DNS lookup so you would definitely need the name to be current.


                When audit data is merged into Track-It!, several checks are done to find a matching asset. If none are found, a new asset is created. This article may be useful as it describes every step that the merge process takes to find a match:




                Not sure why some machines would not be picked up by the scheduled scan, yet audit successfully when you run it manually through Inventory. The only things I can think of is either the machine wasn't available at the time that the scheduled audit ran (sleep mode or similar or turned off) or perhaps the machines aren't enabled for scheduled audits? You can check this by opening one of those machines and looking under the Hardware tab. There is an option that you can toggle for whether you would like the machine to be included in scheduled audits or not. Some users prefer not to audit their servers for example so they disable that option.


                If you have machines that are audited successfully, yet the expected record in Inventory was not updated, it is very likely that the audit data merged into a different asset. The asset you select in Inventory is not necessarily the one that will be updated by the returned audit data. In other words, it doesn't consider what asset you actually have selected when merging the data (see the article above again for the steps taken during a merge). One way to tell which asset was just updated is to add the Audit Date column to the grid and then sort descending so that you will see the latest asset to be updated. That is where the audit data went. There are several reasons why audit data would update a completely different asset, but most often it is due to the machines having been imaged with software such as Ghost, where the original image had been audited at some point. In that case, all imaged machines would contain the same hidden trackitaudit.id file with a unique GUID. That being said, if you are running Track-It! 10.5 Service Pack 1 (, which was just recently released, that should no longer be an issue.


                On the subject of manually edited fields, yes, if you update a value in an asset (talking specifically about the data under the Hardware tab), it becomes "sticky" and future audits will not update it. That would only be the case for specific values that you change. It would not apply to the entire asset.


                IP Address alone should not be an issue. In order for the merge process to update an existing asset based ONLY by IP address, the asset must be a manually created one that has never been audited.

                1 of 1 people found this helpful
                • 5. Re: Trackit Auditing: Some general questions

                  Thanks again Chris


                  I'll have another dig around today and see what else I can find.


                  I can confirm.

                  • All machines in scheduled audit are ticked to include in audit.
                  • We have checked our FOG images and there is no TrackitAudit.id file.
                  • BTW: We are running 10.5 + SP1


                  For the machines it says it has audited successfully and doesn't show any details... I have confirmed that each machine has a unique trackitaudit.id


                  Looking in the workstat table using the keys from trackitaudit.id  with the following query.


                  SELECT *

                  FROM [TRACKIT_DATA].[dbo].[WORKSTAT] 

                  where audit_id ='EF55A3FF-6841-4B51-A038-2F250E5E2AE8' --using each key from each PC.


                  Returns nothing for those machines. And a check on Audit id field doesn't show any duplicates at all. So I presume the data isn't being merged back to a different asset.



                  • 6. Trackit Auditing: Some general questions
                    Chris McLane

                    At this point it may be best for you to contact Technical Support to help work through this. I'm sure they can find the answer.

                    • 7. Trackit Auditing: Some general questions

                      If I may add another question to this subject as well.


                      How does Track-It decide what software shows as Tracked Items after auditing an asset?

                      In order to further test this, we uninstalled an application, the Tracked Items list still shows the application in the list.

                      The application here is MS Windows 2007

                      • 8. Trackit Auditing: Some general questions
                        Chris McLane

                        For an application to be detected as a Tracked Item, it must have certain entries in the registry. This article details exactly what the audit looks for. There is a section specifically in regards to Tracked Items to help explain it:




                        Also, the audit never removes anything from Tracked Items. It only creates them.

                        1 of 1 people found this helpful
                        • 9. Re: Trackit Auditing: Some general questions

                          I've tried removing registries for MS Office from the locations where Track-It looks.No luck


                          So once Track-it detects a Tracked Item, it is never removed even after further audits(assuming said application is uninstalled).Correct?

                          • 10. Re: Trackit Auditing: Some general questions
                            Chris McLane

                            Correct, removing the keys from the registry would only stop future audits from detecting that software as a Tracked Item. Once Tracked Items are added to an asset by the Audit, they are never removed from the existing asset, regardless of what future audits detect.

                            • 11. Re: Trackit Auditing: Some general questions

                              >> At this point it may be best for you to contact

                              >> Technical Support to help work through this.

                              >> I'm sure they can find the answe


                              Thanks Cris, Will do.


                              Apologies for the delay in replying.





                              • 12. Re: Trackit Auditing: Some general questions

                                As suggested I logged a call with our local vendor.


                                We found a few examples of machines that would not audit, and an entry in a logfile stating we didn't have enough licenses. We have now bought an additonl 100 audit licenses, and it seems that has helped. A few machines that could not be audited are now auditing ok. But this doesn't explain all. As I discover more I'll let you know what i find.


                                Can anyone tell me how I can identify if a machine is scheduled to be audited via SQL? I can't find an obvious field that indictaes this in the workstat table?

                                • 13. Trackit Auditing: Some general questions
                                  Chris McLane

                                  It's a column in the WORKSTAT table called ScheduledAuditEligibleFlag.

                                  1 of 1 people found this helpful
                                  • 14. Re: Trackit Auditing: Some general questions

                                    Thanks Chris.


                                    Thats what I thought it should be also. But it doesn't relate to what I can see in the technician client.


                                    According to the query, I have printers and other devices scheduled for audit, but when I look up those assets in inventory, the Interface says they are *not* scheduled for audit. Which should I trust?


                                    In short I am trying to find out which assets and (how many of each type) are scheduled for audit. So I can ensure audit licenses aren't assigned to items we don't want to audit.


                                    select a.[assettype], a.[parentassettypeid], a.[parentassettypeid],  count(w.assettypeid) as scheduled  

                                    from [trackit_data].[dbo].[in_assettype] a, [trackit_data].[dbo].[workstat] w

                                    where a.assettypeid = w.assettypeid

                                    and [scheduledauditeligibleflag] = 1

                                    group by a.[assettype], a.[parentassettypeid], a.[parentassettypeid]


                                    Digging a bit further using the following query...


                                    select a.[assettype], a.[parentassettypeid], w.assettypeid, w.ws_num, [scheduledauditeligibleflag]

                                    from [trackit_data].[dbo].[in_assettype] a, [trackit_data].[dbo].[workstat] w

                                    where a.assettypeid = w.assettypeid

                                    and [scheduledauditeligibleflag] = 1

                                    order by w.assettypeid


                                    I understand only computers and thier subtypes can be audited, but how can I prove or show that non-auditable devices such as printers that have

                                    [scheduledauditeligibleflag]  = 1 are not holding onto an audit license? Or that deleted/retired assets release thier licenses?


                                    If I limit my query by the Computer type and subtype it shows i should have audit licenses free. But recently we exceeded our license count and had to buy more. And so... I would like to know how to verify exactly what machines are being audited and/or using an audit license.


                                    I hope this isn't too technical or specific for the forum. Thanks in advance for any suggestion or assistance.



                                    1 2 Previous Next