"Living" CSV file for reporting?

This topic contains 3 replies, has 3 voices, and was last updated by  Rob Simmers 2 years, 7 months ago.

  • Author
  • #32968


    Is it okay to have a "living" csv file on a share that constantly gets imported locally on various machines and then exported or is there a better way to have a central report when scripts are ran locally on the machine via SCCM package (keeping in mind that remoting is not an option)?

    Basically just looking for the best way to collect data in a single report when the scripts run on each machine (possibly at the same time) via GPO or SCCM.

  • #32973

    Dave Wyatt

    A file is never going to be a good idea for this; you're going to lose data at some point. You either need each computer to write to its own file (so there's no chance of some other system writing to it at the same time), or use a proper DB server.

  • #33002


    Is using a db a normal thing for PowerShell reporting? We often run PowerShell scripts to gather various information and then basically want to know what the script did on that machine in a report. Not sure if I want to give every machine the ability to write to the db.

  • #33003

    Rob Simmers


    I typically do a hybrid approach using a queue based approach. A script gathers configuration details and writes a file to network share, we'll say XML named as Dave eluded (e.g. COMPUTER123_NetworkConfig.xml). I create another script using a scheduled task and that script will process each XML and you could generate a final PSObject and save it as an XML, save it a DB or whatever you wanted to do.

    This approach means that I don't have to worry about clients writing to a database (any ODBC drivers, etc), they are simply creating a file on a network share. Any credentials to write to a database are stored on the server processing the files and\or running the scheduled task as the appropriate credentials keeps elevated permissions in a single place.

You must be logged in to reply to this topic.