There are many ways to initiate an Audit of your computer assets. I break them into two main categories: those initiated from within Track-It!; and those initiated outside of Track-It!
I break them into these categories because how you configure the Admin Console and Merging depends on whether Track-It! initiated the Audit or not.
Audits initiated from within Track-It!
-Audit On Demand
Since Track-It! is aware of these audits, it knows that it will have to do a merge in order to get the results into the database. Track-It! initiates the audit, waits a predetermined amount of time, then automatically launches a merge to process the results.
Track-It! has the ability to queue up all of your computer assets at a time you determine, and go down the list auditing them. You control that time in Admin Console > Configuration > Inventory > Auditing > Scheduled Audits.
When this is enabled, at the indicated time the Track-It! server will take all assets that have an Asset Type of Computer (and any child asset types you create under Computer), and place them into the Audit Queue. It will then go down this list, attempting to audit them a couple of machines at a time. This process relies on the Workstation Manager being properly installed on the target machine.
This can take up to 3 minutes per computer (though typically it's closer to a minute or a minute and a half per computer). For this reason, if you’re queuing a large number (400+ computers) on a daily basis, you may be adding to the queue faster than Track-It! is clearing the queue. Over time, you can end up with a logjam in the queue.
To view the queue, go to Admin Console > Configuration > Inventory > Auditing > Queue. Here you’ll see both the Current Queue, and Queue History. It’s also a good idea to periodically clear Queue History, as it will grow over time and eventually cause excessive time delays in opening the Queue History window, as well as possibly causing delays in auditing in severe cases.
Audit On Demand
This is simply an Audit Now evolution. You can right click a computer in the Inventory module, and one of the options you’ll see is Audit Now. You can use the Shift + Click or Ctrl + Click to select more than one, then use Audit Now for the entire lot.
This adds that machine (or machines) to the end of the audit queue, so if there are any machines already queued up in the Current Queue, you’ll have to wait in line for your machine(s) to be audited.
This also relies on the Workstation Manager.
Audits initiated outside of Track-It!
Audits can easily be initiated outside of Track-It! in any number of ways:
-A user can browse to \\<Track-It! server>\<Track-It! share>\ and double click on audit.exe, or click a Desktop icon that points to that location.
-You can add a line to your login scripts, similar to \\<server>\<share>\audit.exe
-You can use a GPO or any other process that you can configure to run a batch file or executable on a workstation.
The short answer is, all you have to do is get audit.exe to run on a target machine through some triggering mechanism.
Any time the audit runs outside of Track-It!, it checks the configuration page in Admin Console > Configuration > Inventory > Auditing > Manual Audit Restrictions, to see what you want it to do. If there’s a checkmark in the “Limit the number … to once a day” dialog, and the audit has already run today, then the audit will immediately exit without returning an XML file to the Track-It! server.
If the audit is initiated outside of Track-It! on Monday, and there’s no checkmark for Monday under “Specific Day of Week”, the audit again will immediately exit without returning results to the Track-It! server.
Those two settings are very handy for fine-tuning audit’s behavior when you use a login script as the initiating trigger.
A common concern I hear when discussing login script-initiated audits: “That will add to the time it takes for a user to log in.” If you preface the command with the standard DOS “start” command:
then the login script won’t wait for the audit to complete; it will launch the audit as a background process and continue on. In this situation, the audit can still be running in the background after the login script as exited, and the user will have no idea that it’s even there, unless they happen to bring up Task Manager and see it.
Since this is standard DOS, you can customize this in nearly unlimited ways. For example, if you have a lot of RDP/Citrix, and you don’t want to initiate audits when a user logs into one of those sessions, you simply include logic to check for the %SESSINONAME% variable, and not audit unless that variable = Console, something like this:
If %SESSIONNAME% == Console start \\<server>\<share>\audit.exe
When audits are initiated outside of Track-It!, then the server is unaware that audit results are coming into the \Data directory; and so, it’s unaware that it needs to run a merge to process them. In this case, you’d use Admin Console >Configuration > Inventory > Merging > Schedule, and set up a recurring merge process.
There are two choices here, and the one you should select depends on your individual situation.
-Automatically merge on interval
-Automatically merge daily
Automatically merge on interval
You can set the merge process to check every hour or so for audit results, and process them if found. This will give you almost real-time results. For example, if you add a new machine for a user, that machine should automatically show up in Track-It! within an hour or so of the user running the login script.
The downside to this option is the potential for performance hits, especially early in the morning. The merge process can be resource intensive. If everyone logs in early Monday morning and gets audited, and then a merge kicks off an hour later, the Track-It! server is going to be heavily loaded for some time while it processes through hundreds of audit results. Depending on the number of audit results and the hardware specs you’re running Track-It! on, this may have too big of a negative impact on performance.
Automatically merge daily
For situations where performance is a concern, this might be a better choice. All of the audit results continue to stream in, and sit in the \Data folder. At some time in the evening when there’s minimum use n the Track-It! server, a merge kicks off and processes all of the audit results.
This has the benefit of imposing no performance loss during the normal workday. The downside is, any new machine that gets audited today doesn’t show up in the Inventory module until after the merge, and you won't see it until tomorrow.