PROBLEM:
Patch Assessment queries return "Failed to rename result file from (C:\Program Files\Symantec\BVNTQE\Data\FILENAME.tmp to FILENAME.ajd or aje error: 2 . The system cannot find the file specified"
EXPLANATION:
Whether you are attempting to use the Reporting and Analytics Suite or the CCS Data Collector\bv-Control for Windows application, this process is practically identical, since R&A uses bv-Control as the back end for data collection.
Distribution rules are a
definite necessity, expecially when your AD structure spans a wide area, through many subnets and countries. These rules will force Query Engines local to the servers they need to collect data from to do the work.
Data collection will be difficult if the network links to the scoped servers are poor and/or, if the number of targets any given Query Engine must collect from are excessive in comparison to the resources available on the Query Engine, as well as how busy those servers are at the time the query is running. I have a 4x5 foot Visio diagram on my cube wall that shows the network speeds and how each site is connected in AD, which is my main tool for developing my QE architecture.
If any combination of the issues listed above are a part of the equation, the result can cause the Data Collection Agent spawned by the Query Engine to hang , which prevents Atomic Jobs spawned by the DCAs from being transferred back to the QE, causing the Query Engine to time out waiting for the data. Atomic jobs create tmp files during collection that will either have an *.ajd extention, which contain results, or a *.aje extention, which indicates errors, that must be able to transfer successfully back to the snap end for your report to be complete.
You may or may not be able to locate these *.ajd or *.aje files as a clean up routine should remove them from the QE, but some times they aren't removed properly.
TROUBLESHOOTING TIPS:
1) Run your patch assessment query in bv-Control for Windows, scoped to same collection used in R&A.
2) Review the Messages tab from the query results to identify which Query Engines are timing out.
3) Investigate the failing QE; available resources/how busy the server is, network link, number of targets its trying to collect data from. Based on this analysis, you might want to move the QE to a more powerful server, or add another QE to that location, then add it to the Distribution Rules for that site.
4) If you love you look at logs, you can also enable verbose QE error loging on the suspect QE via bv-Config,
- Select the query, Query Engine Settings, Error logging. - Enable
- By default, this will create C:\BVNTError .log.
- You do NOT have to restart the QE to enable this feature.
This the logs or this analysis don't allow you to resolve the issue internally, at least you'll already have evidence available to give tech support when you open a new case! :-D
Peace Out ~