Houston Security User Group

 View Only
  • 1.  Failed to Rename Result File Error

    Posted Feb 26, 2010 09:32 AM
    I am conducting data collection for a Windows patch assessment standard and I receive an error mesage like the following:

    SERVERNAME - Failed to rename result file from (D:\Program Files\Symantec\BVNTQE\Data\9D8995CC-7EA1-4BCA-BB11-8C4957ED4A71-215.ajd.TCBMIS04.tmp)
    into (D:\Program Files\Symantec\BVNTQE\Data\9D8995CC-7EA1-4BCA-BB11-8C4957ED4A71-225.ajd), error: 2 - The system cannot find the file specified.

    I am collecting data against 800 servers using only three query engines. All CCS data collection and BindView components are up-to-date (version 9.0.1).  All the Windows servers are agentless.

    Have you seen this error before?  How do you troubleshoot or resolve it? 


  • 2.  RE: Failed to Rename Result File Error

    Posted Feb 28, 2010 07:26 AM
    Hi,

    Apparently this is a result of QE time out! Hope this will solve your problem.

    http://service1.symantec.com/support/intrusiondetectkb.nsf/854fa02b4f5013678825731a007d06af/3a168c4f72316c64882576d60062f873?OpenDocument

    Cheers,
    Farhaan



  • 3.  RE: Failed to Rename Result File Error

    Posted Mar 02, 2010 08:51 AM
    I have had a Technical Support Case open on this issue since 2/9/10, I have made the registry change for "MaxTimeBeforeTerminate", and still receive errors as above.  I too have 9.0.1 and trying to collect on hundreds of windows servers.


  • 4.  RE: Failed to Rename Result File Error

    Posted Mar 03, 2010 12:28 AM

    Have you tried using the distribution rules ? I personally have noticed that distribution rules helps in the scenario where you've hundreds of servers to report on and it kinda becomes a necessity to dictate the QEs what to do. Additionally, you can try further extending the "MaxTimeBeforeTerminate".




  • 5.  RE: Failed to Rename Result File Error

    Posted Mar 03, 2010 05:04 PM
    I've set up distribution rules, modified the registry key, and reduced the number of servers in a data collection to about 100.  A certain group of servers are still producing this error.  I wonder if it is related to policy settings on the server or services that are not running?


  • 6.  RE: Failed to Rename Result File Error

    Posted Mar 04, 2010 01:03 AM
    Try running normal queries on the group of servers which are throwing the error when you run the patch assessment queries and see what you get. This way we'll know if something is stopping on the server side.  Alternatively you can also run the patch assessment query from RMS and view the task status if the data is getting pulled from the target servers. I've run both the patch assessment query and the standard for a group of 200 servers in one go and it worked fine, but after applying the distribution rules.

    If the problem still persists, I think it'll be better to involve the Symantec Support !!


  • 7.  RE: Failed to Rename Result File Error

    Posted Mar 04, 2010 11:30 AM
    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 ~